On Mon, 27 Sep 2010, der Mouse wrote:
POSIX.1e "capabilities" are actually coarse-grained OS privileges,
Not all that coarse-grained as compared to traditional Unix privileges!
Certainly true :-).
However, they are coarse to the point of being relativley unusable for most
purposes. It's nice to be able to assign the right to bind low port numbers,
but it's preferable to be able to assign a specific low port number. In
practice, that need is better met by an ACL model (bind can bind port X,
apache can bind port Y); since UNIX supports file descriptor passing already,
we can implement that ACL in userspace and use a capability-like approach to
pass it to the daemon rather than adding a new ACL model in kernel. Only,
wouldn't it be nice if we could do that with other things too, within an
application...
Capabilities in a classic security sense are unforgeable tokens of
authority that can be delegated.
Sounds a lot like POSIX "capabilities" to me - it's just that the authority
comes in, as compared to non-POSIX "capabilities", relatively coarse chunks
and is passed around in a rather different way.
I can see the argument here, but am not sure I really agree. The reason that
I feel that POSIX capabilities don't align well with history notions of
capability is that they can't be delegated between processes
non-hierarchically, or even after a child has forked(), without resorting to
tagging them on to executables (similar to setuid binaries) in the global file
system namespace. In classic capability system designs, the idea of
non-hierarchical delegation is central as it allows applications to define
their own security models (see also CAP, Hydra, Eros, etc). Often it's done
via the abstraction of a namespace, but the implementation of the namespace
can be entirely controlled by the service or application.
About ten years ago, I experimented with delegating UNIX privileges using file
descriptors ("tokens"), but wasn't satisfied with the composition properties,
so didn't reuse the idea in Capsicum. In particular, the existing file
descriptor behaviour of UNIX seems to align well with capability concepts in a
way likely to work well with current applications (not a coincidence, of
course, but hence using that as the starting point in Capsicum), whereas many
existing UNIX programs have strong notions of manipulating privilege using
UIDs rather than as file rights. While it seemed that correct usage was
likely possible, the potential for something catastrophic was worrying.
An example of the kinds of things that easily go wrong when modifying the UNIX
privilege model include the Linux privileges + sendmail bug: in the particular
composition they selected, setuid root programs that weren't written to the
new privilege model might end up with their privilege masks set in unexpected
ways, and would therefore fail unexpectedly. While it was undoubtably poor
programming practice that sendmail didn't check whether setuid() failed when
getuid() had returned 0, it wasn't incorrect until the privilege model was
modified without revisiting the assumptions of all applications that depended
on it. You might argue that this problem occurred because the model selected
in Linux allowed negative delegation of rights, violating the privilege
escalation assumption of setuid binaries.
Robert
