Re: caps in elf, next itteration (the hack get's bigger)
thospel@mail.dma.be
Thu, 15 Apr 1999 02:13:04 +0200
In article <199904131657.MAA09864@dcl>,
"Theodore Y. Ts'o" <tytso@MIT.EDU> writes:
> Date: Tue, 13 Apr 1999 12:31:14 -0400 (EDT)
> From: "David L. Parsley (lkml account)" <kparse@salem.k12.va.us>
>
> I'm curious, Dr. von Brand; have you considered stickybit + immutable? (as
> explained in my recent treatise to Richard ;-) It solves a lot of
> problems and gives us:
>
> That's actually the best alternative I've heard to date.
>
> My objection to using setuid root as the flag is that this means that
> even if you don't have root account (as Richard Gooch suggests), it
> still is a problem because there are a huge number of executables that
> are setuid root. And presumably, if a setuid root executable doesn't
> have a capability information, then it in effect becomes setuid root
> again. So it makes it easy for an attacker to hide a setuid root
> executable in a capability system. This is why folks would be much
> happier being able to make UID == 0 have no special capabilities worth
> speaking about.
>
> I suppose you could simply make a capibility-enabled kernel ignore the
> setuid bit on setuid root executables that have no capabilities set. It
> still doesn't solve the problem which Stephen brought up which is that
> you might want an executable to be setuid to some userid (such as
> daemon) and yet still have capabilities. So the stickybit + immutable
> is probably the best alternative heard to date.
>
> - Ted
>
Yes, I also like the sticky bit proposal. But immutable removes much of
the advantages again (nsf/cp/tar stop working). Much better is that writing
to a sticky file just removes the sticky bit except if the entity writing
has CAPSETCAP. Notice that this is also the way we handle suid-ness, which has
exactly the same problem (we don't want someone to write to suid either) and
of which we know it's a working method.
For the same reason I think it's good to introduce a nosticky mount option in
a capabilities kernel, where nosticky is even the default. Once you
audited a filesystem, you can mount it as sticky, so the sticky bits will
have their effect. That solves much of the problem of moving from a non-cap
to a cap kernel.
It also allows things to work in a mixed environment with mounts from
untrusted places. Or user floppy mounts/cd mounts and stuff like that.
This scheme to me seems to solve almost all problems really.
-
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/