Re: Security by hiding processes

From: Michal Zalewski (lcamtuf@coredump.cx)
Date: 07/23/02


Date: Tue, 23 Jul 2002 16:44:56 -0400 (EDT)
From: Michal Zalewski <lcamtuf@coredump.cx>
To: ellipse <ellipse@cipherpunks.com>

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 [lcamtuf@bos.bindview.com] [security]
[http://lcamtuf.coredump.cx] <=-=> bash$ :(){ :|:&};:
=-=> Did you know that clones never use mirrors? <=-=
          http://lcamtuf.coredump.cx/photo/