Messages in this thread |  | | From | Albert Cahalan <> | Subject | Re: /proc/<pid>/mem unreadable | Date | Sat, 4 May 1996 21:05:01 -0400 (EDT) |
| |
>>> 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.
|  |