lkml.org 
[lkml]   [2000]   [Feb]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Capabilities
Date
From
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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.060 / U:0.480 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site