> > who says the [root owned] +s, capability-enabled binaries need to be +x ?
> ^^^^^^^^^^^^
> IMHO, that's the problem right there. In a true capabilities-based
> system, it should be possible to have a cap-enabled binary which is
> owned by another user, and may or may not be setuid. Using the sticky
> bit gives us _very_ nearly complete capabilities support, as well as
> the same compatibility benefits.
True. Relying on root-ownedness is a copout if the goal is real
capability model --> making 'uid 0' unspecial.
> The two real problems I've seen with the sticky bit solution are both
> quite solvable, if we just _think_ about solving them.
I'm not so sure about that. Relying on a mount-time option to say "the
server knows that +t is special, so will be careful with it" would be a
necessary step for NFS. But of course this means that people with
/usr/local NFS mounted from their big-iron NFS server can't have any
capabilities-aware proggies in /usr/local. This (treating +t as
special and security-important) isn't something we can fix, because it
isn't only Linux that needs to care. And nobody but Linux does/will
care.
The reason to accept the root-owned +s copout is that it is a case which
has a prayer of treated somewhat correctly by systems (NFS servers,
older kernels, alternate OSs which grok ext2, etc) even when those
systems don't have a clue what Linux capabilities mean. I don't know if
+t is reasonable because it lacks that historical protection.
We've talked rounds recently about how to enable capabilities in the
[something] where something is filesystem, files, or whatnot, and about
not wanting to break backwards compatability with existing tools,
established FS / network FS standards, etc. But (other than some
interesting tidbits about VMS :) I haven't seen people talk much about
how other UNIXes have attempted to handle this issue. Are there
existing UNIXes which have a capability model at all analagous to what's
being done w/Linux, and if so, what were their answers to these issues
-- and were those answers good ones?
I suspect there are people lurking who know the answer to this, and that
we're all missing something -- which is why they are ignoring us and
writing code ;)
Hank Leininger <hlein@progressive-comp.com>
-
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/