[lkml]   [1996]   [May]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: /proc/<pid>/mem unreadable
>>> The same happened to me. The problem is that strace accesses
>>> the tracee's memory through /proc/<pid>/mem but as of 1.3.96
>>> any read from processes different from the one which owns the
>>> memory fail with EACCES.
>>> This looks like an overly-conservative patch for the
>>> /proc/<pid>/mem security hole involving setuid programs. The
>>> kernel should really return EACCESS only if the process we are
>>> trying to read is setuid.
>>> From what I caught of the discussion, you can start watching
>>> the process's memory, then have the process 'exec' something
>>> suid root, and read straight through the suid root memory.
>>Seems to me that the answer, then, is to have /prov/<pid>/mem mod 600
>>and owned by the euid of the process, rather than owned by the uid
>>that ran it. Linus?
> Whoops, I misspoke. It's already 600 and owned by the euid; the hole
> involves opening the fd before the exec and holding on to it while it
> changes modes. At that point, the fd needs to be somehow invalidated
> for non-root processes.

Maybe do this a different way. Instead of invalidating the fd,
prevent the situation. Don't let a process exec a suid binary
while the /proc/*/mem file is open.


Other stuff:

What about suid scripts? We can lock the inodes, substitute
filenames in /proc for the provided ones, prevent exec accross
network filesystems, clear unknown/unsafe environment variables,
require an explicit interpreter... Whatever is needed. I'd suggest
a binfmt_ss.c for this, so that the paranoid won't have to panic.

 \ /
  Last update: 2005-03-22 13:37    [W:0.096 / U:1.592 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site