Messages in this thread | | | Subject | Re: New Security Features, Please Comment | From | Miquel van Smoorenburg <> | Date | Thu, 04 Dec 2008 00:39:23 +0100 |
| |
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.
| |