Messages in this thread | | | Subject | Re: Capabilities | Date | Mon, 21 Feb 2000 18:03:34 -0300 | From | Horst von Brand <> |
| |
Khimenko Victor <khim@dell.sch57.msk.ru> said: > On Mon, 21 Feb 2000, Horst von Brand wrote: > > Khimenko Victor <khim@dell.sch57.msk.ru> said: > > > On Sun, 20 Feb 2000, Horst von Brand wrote:
[...]
> > > Few ??? All current suid programsshould be converted.
> > Yes. And there are not that many of them around. Here I have 2098 > > executables in /bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin, of which 69 > > are SUID or SGID, a 3.2% of the total. Perhaps a server-style machine would > > have a few more than that, and less general executables.
> You are wrong here :-) LOTS of daemons DO NOT have suid/sgid bit but > should be modified anyway. For example apache: it starts from root, then > bind to 80 port and after fork drop capabilities by changing uid. In > "trusted Linux" apache should be suid apache and will have capability to > bind on port below 1024 (it'll drop this capability after fork). Plus only > few selected users should have rights to execute /usr/sbin/apache (thus > you need ACL and capabilities in filesystem). More or less the same > changes are needed to sendmail and ftpd, pop3d and imapd... All mentioned > programs are not suid now...
sendmail is SUID root here, no httpd around. pop3d, imap and a whole lot of other daemons run from inetd and get their input pre-opened. ftpd is SUID root as it has to do a chroot(2).
[...]
> Changes in filesystem should come first: you CAN change filesystemlayout > and cook up few test programs without capable-aware find(1), but you can > not make capable-aware find(1) if there are no capable-aware filesystem > and API for that filesystem (find SHOULD NOT and WILL NOT access > filesystem directly).
The idea is sound and has been checked. What is needed is to fill in details that only extensive use will tell you how to do right: What capabilities do you define, what programs get which ones of them. Then you need to convince the whole world to port their favorite servers (MTA, FTP, HTTP, ...) to the new scheme, while keeping them working on less enlightened operating systems and ones with a completely different idea of capabilities. No amount of test programs will tell you how Trusted White Socks Linux will hold up in sysadmin's hands and under fire from crackers and other vermin from all over the place. IMO, those are the real questions now. And if you reread at the Halloween papers, this is exactly the kind of challenge (no beaten path to follow) that Microsoft predicted the OSS community would not be able to tackle. I think we are going to prove them wrong (again), but it _is_ a difficult road ahead. -- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Viña del Mar, Chile +56 32 672616
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |