[future patch] dropping user privileges on demand

[ari]

oremanj at get-linux.org said this stuff:

> On Thu, Aug 21, 2003 at 12:39:00AM -0700 or thereabouts, Kris Kennaway wrote:
> > 
> > Exercise for the reader: find a situation where the failure to perform
> > a syscall that normally succeeds, leads to privilege escalation :-)
> 
> setuid(), seteuid(), setruid()

There seems to be some misunderstanding of what kris meant.  He was
referring to a system call that is so poised to succeed that programmers
will often not bother checking for an error value.

For example, if one winds up not having privileges to call exit(), then,
say, an authentication failure may not abort execution.  If close() is
not allowed, then a sensitive file descriptor may be left open as the
program continues to run.  If unlink() fails, one may fall victim to
following an unintended symbolic link upon file creation.  If chroot()
or chdir() fails, a program may not be able to properly insert itself
into a chroot() environment.  If getpid() fails, the program may not
properly distinguish intended privileges.  If mprotect() fails, one may
not be able to remove the writable bit from a memory page.  If munmap()
fails, one may suffer memory leaks.  If quotactl fails, user quotas may
not take effect.

The setuid() family of functions will only cause a problem here if a
program is either running as root or has a saved or effective uid that
is different from its real uid.  Even then, having setuid() disabled may
be either beneficial or detrimental, depending on what the programmer
expects or is attempting.

There are all sorts of ways for the failure of system calls at
inopportune times to lead to an elevation of privileges.  But the point
is, this isn't (or shouldn't be) for the administrator to worry about;
the programmer knows that while modifying his code, he should be careful
not to introduce security problems.  If a programmer is able to disable
the exit() system call, he should know what he's getting himself into
when he does so.

The patch i'm proposing isn't going to allow the disabling of arbitrary
system calls; not every function call will even be included in a class.
For example, the ability to block memory-related routines would probably
not be a good idea, and doing so may break your program, depending
merely on which standard c library you use.  If you expect memory leaks,
resource limits can keep your process at bay.

ari