[546] in linux-security and linux-alert archive
/proc insecurity
daemon@ATHENA.MIT.EDU (Marek Michalkiewicz)
Wed Jan 3 17:13:43 1996
From: Marek Michalkiewicz <marekm@i17linuxb.ists.pwr.wroc.pl>
To: linux-kernel@vger.rutgers.edu, linux-security@tarsier.cv.nrao.edu
Date: Wed, 3 Jan 1996 21:33:34 +0100 (MET)
Hi all!
As we probably already know, the /proc filesystem still has security
problems. Here is another (simpler) idea how to fix it. I came up
with it last night - I just can't sleep well until this is fixed... :)
Note that this has not been tested, and I don't have any real patches
yet, but it looks reasonably easy to implement. The question: is this
enough? Any obvious problems that I missed? Comments?
The problem is that one can open /proc/<pid>/mem, hold the file
descriptor, then have <pid> exec some setuid/setgid/unreadable program
and still read its memory even though the process is not dumpable (for
a good reason - it may have access to sensitive information which
shouldn't be available to the user, example: ssh and secret host key).
1.3.xx
======
How about this: for every process track the /proc/<pid>/mem open count
(add a new field to struct task_struct). You can do that using the
open/release operations, initialize it to zero for the initial task,
and set it to zero for a newly created child process in fork().
Now, if this count is nonzero for the current process, and we try to
exec a setuid program, behave as if the process was ptraced: execute
it but ignore the setuid and setgid bits.
While working on this I noticed one more potential problem: it is
possible to ptrace unreadable programs (the process becomes undumpable
but only _after_ it is ptraced). To test: run strace on any binary
which you can execute but can't read. It will work, and it may reveal
some potentially sensitive information as well. Even if strace can't
read /proc/<pid>/mem anymore, system call arguments may still contain
some sensitive information.
Suggested fix: if the process is ptraced or the /proc/<pid>/mem open
count is nonzero, and we try to exec a program, check that it is
readable by the user, not only executable. If it is not readable,
refuse to execute it and return an error.
Please look at possible problems with this, and comment on it.
1.2.xx
======
For 1.2.xx, there is an additional problem with /proc permissions
getting out of sync with reality. This has been fixed somewhere in
1.3.xx, but probably requires too many changes to put it 1.2.xx.
The only simple fix I can see for 1.2.xx is to make /proc/<pid>/*
owned by root for all processes.
This may break some things (strace will not show data passed to system
calls using pointers, it will only show the pointers), but at least
you can have a choice: less insecure /proc (default) and a few things
broken slightly, or the old behaviour (using the "insecure" /proc mount
option) if you don't care about security.
BTW: strace is not a Linux-specific program (the source says it works
on sunos4 too, which has no /proc filesystem) - it should be possible
to modify it so that it does not assume /proc/<pid>/mem is available.
If it isn't, fall back to using the ptrace system call. Possible?
If there will be 1.2.14 (please...), here are other security problems
to fix besides /proc (just a reminder):
- MAP_DENYWRITE denial of service
- setuid/setgid bits not cleared on write by non-owner
I will try to make /proc patches for 1.2.xx and 1.3.xx (as described
above) available in a week or two.
Regards,
Marek
