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:
>
> [...]
>
> > > Owners (UIDs) don't have capabilities. Processes have them, and that is
> > > something that is recorded in the filesystem for the executable (like
> > > SUID/SGUID is today).
>
> > You want to remove SUID/SGID from trusted Linux ???? It'll be wrong move
> > IMO. SUID/SGID to "normal user" is not covered by capabilities!
>
> No I don't. It makes perfect sense to have a program SUID/SGID so it can
> manipulate certain files. That is a minor use of SUID today, it is used
> mostly (via SUID root) to give a program capabilities; it will be the only
> use in a capability system.
>
> [...]
>
> > > Exactly. It is a either/or situation. You might run backward compatible
> > > stuff as SUID root with all capabilities, but that negates most of the
> > > advantages. Luckily, the capable programs will be few (at least initially).
>
> > 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...
> [...]
>
> > > Problem is, now you identified where we are going. We know where we
> > > are. How to we get there? ;-)
>
> > Ok. We should implement kernel changes (capabilities in filesystem,
> > conpile-time selection and so on) and ask distribution makers to do the
> > rest (to convert userspace to new mode). Other way look like try to cut
> > cat's tail in parts (oh, I love my cat too much, I can not cut his tail in
> > one shot -- I'll do so in parts :-)... All proposed solutions to
> > "transition problem" are worse then problem itself.
>
> Again, the changes are in system-wide, security-critical services
> _only_. But a lot of new tools will have to appear: Capable-aware find(1),
> tar(1) (Or its equivalent), dump/restore(8), ls(1), chmod(1) (or
> chcap(8))... And as long as the filesystem format (including ACLs too)
> isn't defined, nobody will write/port them. And if they don't exist,
> changes in the filesystem are useless...
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).
-
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:26 EST