Linuxのhidepid設定入門｜procfsのアクセス制限でプロセス情報の横断漏洩を防ぐ実践ガイド

Linuxサーバーを複数のユーザーや複数のアプリケーションで共有しているなら、「procfs（/proc）」のアクセス制御が盲点になっているかもしれません。

デフォルト設定のLinuxでは、一般ユーザーが他のユーザーのプロセス情報――コマンドライン引数・環境変数・実行ファイルパス――を自由に閲覧できる状態になっています。パスワードをコマンドライン引数に渡しているスクリプト、DB接続文字列を環境変数に格納しているアプリケーション……これらは全て、同じサーバーにアクセスできる別ユーザーに筒抜けになりえます。

この記事では、Linuxが標準で提供するhidepidマウントオプションを使って、procfsのアクセスを適切に制限する方法を解説します。設定コマンドから永続化手順・動作確認・よくある落とし穴まで、現場で使えるレベルで網羅します。

procfs（/proc）とは？プロセス情報が「丸見え」になる理由

/proc（procfs）は、Linuxカーネルが実行中のプロセス情報やシステム状態をユーザー空間に公開する仮想ファイルシステムです。ディスク上に実体はなく、カーネルが動的に生成します。

たとえば、PID（プロセスID）が1234のプロセスがあるとき、/proc/1234/以下には次のような情報が並んでいます。

・cmdline: プロセス起動時のコマンドライン引数（ヌル文字区切り）
・environ: プロセスが持つ環境変数の一覧
・exe: 実行中のバイナリへのシンボリックリンク
・fd/: オープン中のファイルディスクリプタ一覧
・status: プロセスの実行UID・GID・状態など

デフォルトのLinuxでは、一般ユーザーが全てのPIDディレクトリを参照できます。/procのパーミッションは世界読み取り可能（dr-xr-xr-x）であり、自分が起動していないプロセスの情報も確認できてしまいます。これは設計上の特性ですが、複数ユーザーが共存する環境では情報漏洩の温床になります。

攻撃者がprocfsをどう悪用するか（敵を知る）

procfsが読み取れると、具体的にどのような情報が漏れるのか見てみましょう。

1. コマンドライン引数に含まれる認証情報の漏洩

データベース接続やAPIコールをコマンドライン引数でパスワードを渡しているスクリプトは珍しくありません。同じサーバーに一般ユーザーとしてログインできる攻撃者は、次のようにして他のプロセスの認証情報を取得できます。

# 攻撃者が実行するコマンド例（同じサーバーに一般ユーザーとしてログイン済みの場合）
$ cat /proc/1234/cmdline | tr '\0' ' '
mysql -u root -pS3cr3tPassw0rd mydb

# 環境変数の確認
$ strings /proc/1234/environ | grep -i pass
DB_PASSWORD=MyProductionPass!
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

侵害された一般アカウントや内部の不正ユーザーが、このようにして他プロセスの認証情報を横取りできてしまいます。

2. 権限昇格の足がかりとしての悪用

procfsから得た情報は、権限昇格攻撃の足がかりになります。root権限で動作しているプロセスのコマンドライン引数・環境変数を読み取ることで、sudoスクリプトの構造を把握したり、cronで実行されるスクリプトへのPATHハイジャックを試みたりする攻撃チェーンが成立します。

3. ファイルディスクリプタからの情報把握

/proc/[pid]/fd/（オープン中ファイルディスクリプタ）を参照すると、そのプロセスが現在どのファイルを開いているかを確認できます。設定ファイルのパスが特定できれば、内容の推測や別経路での読み取り試行につながります。

hidepidとは？3つのモードと動作の違い

hidepidは、/procのマウントオプションとして指定できるアクセス制御機能です。Linux 3.3以降で利用可能で、現在の実用サーバーのほぼ全てで使えます。

本番サーバーではhidepid=2を設定するのが基本です。これにより、一般ユーザーは自分が起動したプロセスしかprocfsから確認できなくなります。

具体的な設定手順

1. 現在の/proc設定を確認する

まず現状を把握します。

# /procのマウントオプション確認
$ mount | grep proc
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)

# hidepidが未設定の場合: 「hidepid=」の記載がない
# hidepid=2設定済みの場合: 「hidepid=2」が含まれる

2. /etc/fstabでhidepid=2を永続化する

/etc/fstabに設定を追加することで、再起動後も有効になります。

# /etc/fstabをバックアップしてから編集
$ sudo cp /etc/fstab /etc/fstab.bak

# /etc/fstabに以下の行を追記（既存のproc行があればコメントアウトしてから追記）
proc    /proc    proc    defaults,hidepid=2    0    0

# 設定を即時反映（再起動なしで適用）
$ sudo mount -o remount,hidepid=2 /proc

# 反映確認
$ mount | grep proc
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime,hidepid=2)

Debian/Ubuntu系ではデフォルトでproc行が存在しないケースがあり、その場合はそのまま追記します。CentOS/Rocky Linux系でも同様の手順で対応できます。

3. systemdのマウントユニットで設定する（代替手順）

/etc/fstabの編集の代わりに、systemdのマウントユニットで管理する方法もあります。systemd環境ではトラブルシューティングしやすい利点があります。

# /etc/systemd/system/proc.mount を作成
$ sudo tee /etc/systemd/system/proc.mount << 'EOF'
[Unit]
Description=Proc filesystem with hidepid=2
DefaultDependencies=no
Before=sysinit.target
After=local-fs.target

[Mount]
What=proc
Where=/proc
Type=proc
Options=nosuid,nodev,noexec,relatime,hidepid=2

[Install]
WantedBy=local-fs.target
EOF

# ユニットを有効化して即時反映
$ sudo systemctl daemon-reload
$ sudo systemctl enable proc.mount
$ sudo mount -o remount,hidepid=2 /proc

4. 設定後の動作確認

別の一般ユーザーアカウントでログインし、hidepidが正しく動作しているか検証します。

# ユーザーAとしてテスト用プロセスを起動
userA$ sleep 3600 &
[1] 5678

# ユーザーBでSSHして確認
userB$ ls /proc/ | grep 5678
# 結果: 何も表示されない（他ユーザーのPIDが見えない）

userB$ cat /proc/5678/cmdline
# 結果: No such file or directory（ディレクトリ自体が不可視）

# 自分のプロセスは問題なく見える
userB$ sleep 100 &
[1] 9999
userB$ cat /proc/9999/cmdline | tr '\0' ' '
sleep 100

この確認で「他ユーザーのPIDが見えない」「自分のプロセスは参照できる」の両方が確認できれば設定成功です。

中小企業でも今日からできること

「Linuxサーバーを複数人で共有している」「Webサーバーが複数のアプリをデプロイしている」――そんな環境であれば、hidepid=2はすぐに設定できる重要なハードニング項目です。

・クラウドVM・VPS（Ubuntu・Rocky Linux等）: デフォルトはhidepid=0。Linuxサーバー初期セキュリティ設定チェックリストと合わせて、新規構築時に必ず組み込みましょう
・Webサーバー・アプリサーバー: PHPやNode.jsがENV変数経由でDB接続文字列を持つケースが多い。hidepid=2で横断漏洩リスクを大幅に低減できます
・CI/CDサーバー・共有開発環境: 複数ユーザーが同時にプロセスを実行する環境では特に効果的です
・マウントオプションとの組み合わせ: noexec・nosuid・nodevオプションとの組み合わせで多層防御が実現できます

また、Linuxのファイルシステムやパーミッションの基礎については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。

よくある誤解と注意点

【注意1】psコマンドやtopで「自分のプロセスしか見えない」ようになる

hidepid=2を設定すると、ps auxやtopが自分のプロセスしか表示しなくなります。これは意図した動作ですが、運用担当者が「サーバーのプロセスが消えた」と混乱するケースがあります。rootユーザーは引き続き全プロセスを確認できますので、管理作業はrootまたはsudoで実施してください。

【注意2】gidオプションで監視ユーザーに例外を設定できる

Zabbix・Prometheusなどの監視エージェントが全プロセスを参照する必要がある場合は、gidオプションを組み合わせます。

# monitoringグループのユーザーは全プロセスを参照可能にする
# /etc/fstabのproc行を以下のように変更
proc    /proc    proc    defaults,hidepid=2,gid=monitoring    0    0

# グループ名の代わりにGIDを直接指定することも可能
# proc    /proc    proc    defaults,hidepid=2,gid=1001    0    0

# 監視ユーザーをmonitoringグループに追加
$ sudo usermod -aG monitoring zabbix
$ sudo mount -o remount,hidepid=2,gid=monitoring /proc

【注意3】Dockerやコンテナ環境での挙動

Dockerコンテナ内のプロセスはホストの/procとは別のpid namespaceで管理されるため、hidepid=2のホスト設定がコンテナに直接影響することは基本的にありません。ただし、コンテナにホストの/procをバインドマウントしている場合は影響を受けます。本番環境ではコンテナのマウント設定を必ず確認してください。

【注意4】hidepidだけで認証情報漏洩を完全に防げるわけではない

hidepid=2はあくまで「横断参照によるプロセス情報漏洩」を防ぐ設定です。根本的な対策は、パスワードをコマンドライン引数や環境変数に直接渡さない設計――設定ファイル（パーミッション600）や秘密管理ツールの活用――にあります。hidepidはそれを補完するハードニングと位置づけてください。

本記事のまとめ

procfsのhidepid設定は、コマンド1行・fstab1行で実装できる割に、プロセス情報の横断漏洩という見落とされがちなリスクに直接対処できます。特に複数ユーザーが共存するサーバーや、環境変数に認証情報を持つアプリケーションが動くWebサーバーでは、今すぐ確認・設定しておきたいハードニング項目です。