On Tue, 23 Jul 2002, ellipse wrote: > A multi-user system should not, in my opinion, have a /proc filesystem > at all.
/proc is good. It is useful for the superuser or management software. It is useful for users, so they can monitor their own resources. It also provides a nice interface to do certain things you couldn't do otherwise - for example, mmap()ing memory of a ptraced program. The issue is completely different - on a multiuser system with untrusted users, none of them should be able to do anything other than a strictly defined subset of operations. Giving full shell access and then elliminating single attack vectors by removing few suids, using a restricted /proc, etc, is a risky task. If you do that, don't blame your problems on others, a typical un*x system is not supposed to protect itself from its own users. There is some basic control, but it is designed to put functionality waaay over security. It's good to protect an university computer from careless users (in that even if the system fails, it does not fail too often, and the damage is acceptable), but is not sufficient to protect a high-profile machine that stores very sensitive information. Sorry. > This is not obscurity. Information leakage is a valid vulnerability. > Anything that by default gives sensitive information to users that > probably shouldn't have it is, by default, broken. Puh-leze - /proc does not automagically "give" the information to others. You have to let them access /proc and many more other, possibly more sensitive components by giving them full shell access, which is pretty irresponsible - that is, if you can't trust your users. /proc is not broken. People who believe that local shell access is suitable for untrusted users on a Very Important Unix Machine are typically wrong in that they give grossly excessive privileges to "bad guys" and then complain. Your typical un*x box is simply not designed to do that, and is too complex to implement "permit by default" policy and then exclude some specific cases without serious consequences sooner or later. > By limiting the amount of information untrusted users can gather, we > limit the vectors of entry for an attack. Depends. -- _____________________________________________________ Michal Zalewski [[EMAIL PROTECTED]] [security] [http://lcamtuf.coredump.cx] <=-=> bash$ :(){ :|:&};: =-=> Did you know that clones never use mirrors? <=-= http://lcamtuf.coredump.cx/photo/
