Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes: > Anyway, the code is there, but processes started at boot time are not in > different login groups, I think. You would want them to be there, though. > In fact, I think you would loose all security at the login shell if there > were processes without owner started at boot time, as login groups are only > created after a login. Is that stuff in a special login group, or no login group at all? Anyway, it should be possible to put those jobs each in a differnt group easily. We're root, then, after all. > > If we could get some kind of compartmentalizing for setuid(-1), so that > > the apache threads would have access to each other, but not to bind or > > the ftpd, and soforth, it could work, but this would again be totally > > incompatible with all other systems. > > If you put them in a login group, this could work out right now. I am not > sure what you mean with compatible here. Øystein probably meant the fact that running apache, bind, and friends all as "nobody" is the completely wrong thing to do on Unix, while it would be Right on the Hurd in our scenario. But the Hurd is "downwards" compatible: running bind as user "bind", apache as "www-data", etc. will not be unsafe here ... Packages could go with the portably safe solution of using their own uid on GNU, too, or put in a special case to just use nobody here, saving on /etc/passwd clutter. > > Am I totally off here? I'm not sure how you would combine "no > > privileges" with "actually being able to do something useful". I'm > > quite Unixified in my knowledge, so perhaps it is only a question of > > unlearning a bit more ;) > > The programs can access the filesystems through the fourth set of access > bits. By default, they are the same as the bits for "other". Don't forget that already owned capabilities (mainly open file handles -- what about other port rights??) should also stay available. So bind could open all its config and cache files, arrange its sockets, and then drop all uids, still being able to send/recv packets, and read/write the files. -- Robbe
Attachment:
signature.ng
Description: PGP signature