/proc/$PIDのファイル(ssh-agent、Chromeなど)は、ユーザーに属さずにrootに属します。

/proc/$PIDのファイル(ssh-agent、Chromeなど)は、ユーザーに属さずにrootに属します。

私はここで別の質問に答えています:-)、一度見てください –求めるどのソケットを使用しているかを/proc/$PID/fd確認してください。ssh-agentしかし、私はできません。ほとんどのファイルとディレクトリがルートディレクトリに属していることに驚きました。ssh-agent親プロセスと同様に、私のユーザーとして実行され、SUIDルートがインストールされていません。 KDEが正確にどこから始まるのかわかりません。気になりました。ここで何が起こっているのか教えていただけますか?

それとも、これはユーザーと全く関係がなく、プロセスはいくつかのカーネル魔法を使用して/proc公開(または同じユーザーの他のプロセス)から情報の大部分を隠すことができますか?

/proc/$PID/fdすべてのプロセスを確認した結果、このssh-agent異常な属性がこのプロセスだけではないことがわかりました。他のものは多数のChromeプロセスですkdesud(SUIDルートバイナリもありません)。

答え1

[次は、プロセスに追加したばかりのテキストを修正したものです。工程(5)マニュアルページはこの質問に答えます。 ]

次のファイルは/proc/PID通常、プロセスの有効なユーザーと有効なグループIDによって所有されます。ただし、セキュリティ対策として、root:rootプロセスの「dumpable」属性が1以外の値に設定されている場合、所有権が付与されます。 [この属性のデフォルト値は 1 です。このプロパティを0に設定すると、重要な情報が含まれる可能性があるため、プロセスはコアダンプを生成しません。同様に、特定のファイルは/proc/PID機密情報へのアクセスを提供できます。 ]

このプロパティは、次の理由で変更される可能性があります。

  1. この属性はアクションを介して明示的に設定されますprctl(2) PR_SET_DUMPABLE
  2. 属性がファイルの値にリセットされました/proc/sys/fs/suid_dumpable

デフォルト値は/proc/sys/fs/suid_dumpable0 です。ダンプ可能な属性をファイルの値にリセットできる理由はsuid_dumpable次のとおりです。prctl(2)マニュアルページ:

  • プロセスの有効なユーザーまたはグループIDが変更されました。
  • プロセスのファイルシステムユーザーまたはグループIDが変更されました。
  • プロセスは、set-user-ID、set-group-IDプログラム、またはその機能を持つプログラムを実行します。

答え2

chrome-sandboxChromeの場合はsuidビットがあり、root権限で実行されるためです。

あなたの質問についてはssh-agentわかりませんが、私の場合は/usr/bin/ssh-agentsuidビットが設定されました。つまり、ルートエントリは意味があります。 kdeがssh-agentをどのように処理するかはわかりませんが、suidヘルパーが関連していることは確かです。

一般的に言えば、魔法のようなものはありません。通常、プログラムはsuidビットを持ち、それを明示的に指定するか、CAPABILITIES外部ヘルパープログラムを直接実行するか、または同様の方法で使用する必要がありますpolkit

psこれらのプログラムはrootとして実行されますが、権限を放棄するため、ユーザーとして実行されますが、ファイルはまだsuidビット所有者が所有していることがわかります。

答え3

ディスプレイマネージャ(lightdm、openboxなど)はinitの子であり、rootが所有しています。 Initは非常に特別なプロセスであり、ちょうどuid 0で始まったので、set-uidではありません。このコマンドはps -eaH原点の構造化ビューを提供し、関連ビットは次のとおりです。

r    1 ?        00:00:00 init
r 1521 ?        00:00:00   lightdm
r 1531 tty7     00:00:12     Xorg
m 2035 ?        00:00:00     lightdm
m 2177 ?        00:00:00       gnome-session
m 2225 ?        00:00:00         ssh-agent

プロセス所有者(RootまたはMe)を前に追加しました。 /procは実際のファイルシステムではありませんが、内部カーネル構造へのファイルなどのアクセスを提供し、カーネルは適切であると判断されるすべての権限を設定できます。 2035には実用的で有効なUIDがありますが、/proc/2035のエントリはrootが所有し、/proc/2035/fdには0700(-rx------)権限があります。 2177に達するまで、procにダミーファイルはありません。これは、2177のPPIDがUIDルートではないためです。

なぜ?これは、ルートプログラムによって生成された場合、私のファイルの一部がシステムセキュリティを利用できるためです。以前はそうではありませんでした。/proc/sys/fs/protected_hardlinks の下の proc(5) man コメント:

このファイルのデフォルト値は 0 です。この値を1に設定すると、/ tmpなど、誰でも書き込むことができるディレクトリで最も一般的なハードリンクベースのチェック時間、および使用時間の競合によって引き起こされる長いセキュリティ問題を回避できます。この欠陥を悪用する一般的な方法は、特定のハードリンクをたどると権限の境界を越えることです(つまり、ルートプロセスは他のユーザーが作成したハードリンクに従います)。また、別のパーティションを持たないシステムでは、権限のないユーザーが脆弱なset-user-IDおよびset-group-IDファイルを「固定」して、管理者が特殊ファイルをエスカレーションまたはリンクするのを防ぎます。

この記事では、/proc/fd攻撃ベクトルが悪用される可能性がある理由を正確に説明していませんが、カーネル/fs/procにある数千行のコードよりも良い感じを与えます。

答え4

/ procは特別な擬似ファイルシステムです。からproc(5)man 5 proc):

   The proc file system is a pseudo-file system which is used as an inter-
   face to kernel data structures.  It is commonly mounted at /proc.  Most
   of  it  is  read-only,  but  some  files  allow  kernel variables to be
   changed.

説明については、マニュアルページ全体をお読みください。

関連情報