On Sun, 20 Feb 2000, Horst von Brand wrote:
> "Khimenko Victor" <khim@sch57.msk.ru> said:
> > In <200002200217.e1K2HZ216763@sleipnir.valparaiso.cl> Horst von Brand
> > (vonbrand@sleipnir.valparaiso.cl) wrote:
>
> [...]
>
> > HB> I fail to see the connection between filesystem and proceses being
> > HB> able (or not) to bind to a low port, for instance. OK, so if your
> > HB> httpd resides on FAT, it has no capabilities and won't work at all.
>
> > No. It WILL work. It will inherit needed capabilities from it's owner.
>
> 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!
> > But
> > yes, now I found that quite a few other things should be changed in
> > "trusted Linux" (for example now apache start with UID=0 so it has all
> > capabilities and then with change of UID it'll drop all capabilities; in
> > trusted system even with change of UID capabilities will retain: UID==0
> > is not special in "trusted Linux"). So system-wide option looks
> > unavoidable :-(( Perhaps it should be compile-time option even: daemons
> > like apache and bind should be changed significally to work in "trusted
> > Linux" so there are no point in allowing to swicth between trusted/non
> > trusted more "on the fly".
>
> 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.
> [...]
>
> > HB> But AFAIKS capabilities is a systemwide decision. And even if it wasn't,
> > HB> binding this to the specific filesystem (or mount flags) is extra
> > HB> complexity, both in-kernel and for the sysadmin. Complexity precisely in
> > HB> the areas where you don't want any of it. No dice.
>
> > Agree. I think that even ability to switch between "trusted" and
> > non-"trusted" modes in run-time is overkill. Changes in system behaviour
> > is too radical...
>
> 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.
-
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