* Linux does not have support for capabilities, it has support for
capability lists (POSIX capabilities are really capability lists). These
are two radically different paradigms and claiming that Linux has
support for capabilities would be a misinformation to say the least (to
put it bluntly: it would be either a lie or clear misunderstanding of
concepts). Please do not confuse the two approaches, and please DO use
the correct terms so that the approaches are not mixed if you don't want
to create a bad image for Linux and its developers (as people read about
capabilities and see Linux claiming to have support for them, they might
think that Linux is more secure than it really is (or can be with
capability lists), creating a false sense of security).
* Don't put authority (that a capability conveys) in the binary and
don't trust processes to not use the authority that they are given. You
want security because you don't want to trust in the first place. Giving
a process the whole authority and hoping that it will drop what it
doesn't need is like giving your housekeeper the key to the safe and
hoping that she'll only clean the house, and not also steal the money in
the safe (and while the housekeeper may be fair and honest and trustable
and all, someone else who could enter the house with her may not).
* There have been some thoughts that the information about authority
that the program has should be as easily obtainable as possible. If
security is at stake, programs should _not_ by default be able to
determine their true authority because that makes operation of troyan
binaries easy (check if you have enough authority; exploit if you do,
don't do anything to arouse suspicion if you don't). Obtaining the
information itself should be a capability that can selectively be given
to or revoked from individual objects.
* (as Vadim E. Kogan already pointed out) From security point of view,
all objects in the system are equal: they all have some rights that they
can excercise (but no other), even though those rights can differ
greatly. This diversity is one of the reasons why capability lists won't
cut it, and it doesn't matter if the list is now 64 (I think the
original proposal was 32) bits long - in time, this list will only grow
longer and the system will become less efficient and more complex (mind
you that complexity and security don't go along very well).
* You can't make a (good security) pie without breaking the (POSIX)
eggs..
Andrej
-- Andrej Presern, andrejp@luz.fe.uni-lj.si
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu