Re: New Security Features, Please Comment

[Miquel van Smoorenburg <miquels@cistron.nl>]

On Wed, 2008-12-03 at 23:08 +0000, Alan Cox wrote:
> > The children are pre-forked, so the overhead is in the setup... then
> > when the app recieves a request, it sets the child's uid to the uid of
> > the website, and then passes the request to the child, which, now, the
> > child is running as the website owner.
> 
> But the child process may already have been trojanned by a previous user
> so it gains you nothing.
> 
> > It is more secure then just doing nothing.
> 
> I'm not convinced. Not remotely.

Well, in this particular case, and with this API, perhaps not.

But there really is something to be said for being able to limit the
setuid range of a process.

Right now, applications that want to switch to several different
UIDs/GIDs must be setuid root themself or at least have the right
capability. But once an app has that it can switch to any uid, including
root or other system users.

It would be great if you could say 'limit setuid() to saved-uid + uids
1000-2000' or something like that.

If then the userlevel NFS server gets owned you can at least be sure
none of the files in /bin have been modified ..

Note that there are patches on the net for linux, freebsd and probably
other OSes that do exactly this, so there definately is a need.

It could even be used to give normal users a range of uids to use for
sandboxes. Just an idea, I haven't really thought that through.

Mike.