Re: Capabilities

From: Horst von Brand (vonbrand@sleipnir.valparaiso.cl)
Date: Mon Feb 21 2000 - 16:03:34 EST


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/



This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:29 EST