4

rootユーザーの下で実行されているプロセスがあります。

ps aux | grep ProcessX
root     11565  0.0  0.7  82120 22976 ?        Ssl  14:57   0:02 ProcessX

ここls -l /proc/11565/で(pid)はこの結果を出します。

total 0
dr-xr-xr-x 2 root root 0 Aug  9 16:06 attr
-rw-r--r-- 1 root root 0 Aug  9 16:06 autogroup
-r-------- 1 root root 0 Aug  9 16:06 auxv
-r--r--r-- 1 root root 0 Aug  9 16:06 cgroup
--w------- 1 root root 0 Aug  9 16:06 clear_refs
-r--r--r-- 1 root root 0 Aug  9 16:06 cmdline
-rw-r--r-- 1 root root 0 Aug  9 16:06 coredump_filter
-r--r--r-- 1 root root 0 Aug  9 16:06 cpuset
lrwxrwxrwx 1 root root 0 Aug  9 16:06 cwd -> /usr/local/bin
-r-------- 1 root root 0 Aug  9 16:06 environ
lrwxrwxrwx 1 root root 0 Aug  9 16:06 exe -> /usr/local/bin/ProcessX
dr-x------ 2 root root 0 Aug  9 16:06 fd
dr-x------ 2 root root 0 Aug  9 16:06 fdinfo
-r-------- 1 root root 0 Aug  9 16:06 io
-rw------- 1 root root 0 Aug  9 16:06 limits
-rw-r--r-- 1 root root 0 Aug  9 16:06 loginuid
-r--r--r-- 1 root root 0 Aug  9 16:06 maps
-rw------- 1 root root 0 Aug  9 16:06 mem
-r--r--r-- 1 root root 0 Aug  9 16:06 mountinfo
-r--r--r-- 1 root root 0 Aug  9 16:06 mounts
-r-------- 1 root root 0 Aug  9 16:06 mountstats
dr-xr-xr-x 6 root root 0 Aug  9 16:06 net
-r--r--r-- 1 root root 0 Aug  9 16:06 numa_maps
-rw-r--r-- 1 root root 0 Aug  9 16:06 oom_adj
-r--r--r-- 1 root root 0 Aug  9 16:06 oom_score
-rw-r--r-- 1 root root 0 Aug  9 16:06 oom_score_adj
-r--r--r-- 1 root root 0 Aug  9 16:06 pagemap
-r--r--r-- 1 root root 0 Aug  9 16:06 personality
lrwxrwxrwx 1 root root 0 Aug  9 16:06 root -> /
-rw-r--r-- 1 root root 0 Aug  9 16:06 sched
-r--r--r-- 1 root root 0 Aug  9 16:06 schedstat
-r--r--r-- 1 root root 0 Aug  9 16:06 sessionid
-r--r--r-- 1 root root 0 Aug  9 16:06 smaps
-r--r--r-- 1 root root 0 Aug  9 16:06 stack
-r--r--r-- 1 root root 0 Aug  9 16:06 stat
-r--r--r-- 1 root root 0 Aug  9 16:06 statm
-r--r--r-- 1 root root 0 Aug  9 16:06 status
-r--r--r-- 1 root root 0 Aug  9 16:06 syscall
dr-xr-xr-x 6 root root 0 Aug  9 16:06 task
-r--r--r-- 1 root root 0 Aug  9 16:06 wchan

これで、ステータスとマップの両方のファイル権限が同じになります(-r--r--r--)。しかし、cat /proc/11565/maps特権のない(rootではない)ユーザーに問題を起こすと、許可が拒否されます。ただし、のcat /proc/11565/status場合、期待どおりに出力されます。

ここに欠けているものはありますか?

4

2 に答える 2

8

これは、ファイルのアクセス許可だけが保護されているわけではないためです。

これらは、ファイル システム上の単なる通常のテキスト ファイルではなく、プロセス内部へのウィンドウであり、ファイルのアクセス許可、他の保護が設定されているprocfs場合の両方を通過する必要があります。

マップには、メモリの使用状況やプロセス空間内の実行可能コードの場所に関する潜在的に危険な情報が表示されます。ASLR を調べてみると、これはコードが読み込まれた場所を潜在的な攻撃者が知るのを防ぐための方法であり、誰でも読み取れるprocfs.

この保護は2007 年に追加されました。

この変更により、マップの内容を読み取るアクセスを許可する前に、「ptrace_may_attach」を使用したチェックが実装されます。この保護を制御するために、新しいノブ /proc/sys/kernel/maps_protect が追加され、対応する procfs ドキュメントが更新されました。

ptrace_may_attach()内部(実際には、それが呼び出す関数の 1 つ内) に次のコードがあります。

if (((current->uid != task->euid) ||
     (current->uid != task->suid) ||
     (current->uid != task->uid) ||
     (current->gid != task->egid) ||
     (current->gid != task->sgid) ||
     (current->gid != task->gid))     && !capable(CAP_SYS_PTRACE))
   return -EPERM;

そのため、同じ実際のユーザー/グループ ID、保存されたユーザー/グループ ID、有効なユーザー/グループ ID (つまり、こっそりsetuidしたものではない) があり、それらがプロセスを所有するユーザー/グループ ID と同じでない限り、その「ファイル」の中を見ることは許可されていません(CAP_SYS_PTRACEもちろん、プロセスに機能がない限り)。

于 2012-08-09T10:56:33.113 に答える