Linux, IRIX, and "POSIX Capabilities"
Sun, 7 Nov 1999 13:50:01 -0800 (PST)
A couple of days ago i attended an SGI event to discuss SGI's
directions and involvement in Linux systems. They are planning
to sell Intel-based machines running Linux, with the SGI logo
stamped on the box. They weren't very clear about the migration
path they expect IRIX software to take, but they do seem to be
very enthusiastic about Linux in general. They plan to contribute
some big chunks of IRIX operating system technology to the Linux
open-source effort, such as their journalling filesystem, XFS,
and improvements to the TCP/IP stack which they claim can enhance
web server performance by up to 10 times. IRIX 6.5 is under C2
evaluation, and Trusted IRIX 6.5 is under B1 evaluation.
I went to a session on "security in Linux" that morning, which was
led by Casey Schaufler <firstname.lastname@example.org>. He is leading the Linux
security development effort, which includes plans to provide the
TCB Definition and Audit Trail required for C2, and the Mandatory
Access Control and Access Control List features required for B1 --
Of course, the mention of "capabilities" caught my attention
immediately. It became clear that what he was talking about was
not our understood meaning of "capability-based security" but
rather "POSIX 1.e capabilities", which are really "privileges" but
somehow got misnamed "capabilities" along the way (how awful!).
Much to my dismay, i have discovered that the terminology collision
is rampant, as in these documents:
"Capabilities done right" (Linux kernel mailing list)
POSIX 1.e Summary
Casey told me that IRIX has had "capabilities" for some time, and
this feature was announced as "capabilities" in IRIX 6.5:
"IRIX 6.5 Security Features", SGI Security Advisory
It was encouraging to see the following document start out by clearly
defining the difference between capabilities and privileges -- but
then it goes on to ignore its definition and call POSIX privileges
Linux Capability FAQ
Similarly, the feature is entitled "linux-privs" by the following
documentation -- but called "capabilities" throughout.
The library is called "libcap", and many of the symbols and constants
start with "cap" or "CAP_".
A quick look at the linux-kernel mailing list shows lots and lots of
messages about "capabilities".
I went up to chat with Casey after his presentation, and discuss
capabilities vs. privileges with him. Summary:
- He's clear on the two meanings of "capability". He thinks
the name collision is unfortunate but that nothing can be
done about it. (He refers to our model as the kind of
capabilities based on "tickets" and the other model as
- He explained to be "POSIX capabilities" (or "privileges")
as "privileges to violate security restrictions".
- He agrees that Java does not solve the confinement problem.
- He believes the main problem is controlling the propagation
of authority. I called it the confinement problem. We are
probably talking about the same thing, but when he calls it
"propagation of authority" it leads him to think about the
operating system giving or not giving an entity the
permission to propagate, etc.
- He gave an example of someone giving him an authority, and
him abusing it. If he does not have the "privilege" to pass
it on, then an auditor can determine that he must be the one
responsible for the abuse. With "ticket-based" capabilities,
if he passes on the authority to me, and i shoot him, and
then abuse the authority, the abuse is untraceable.
- I responded by saying that if he and i are co-operating
conspirators, and he willingly passed me the authority, there
is nothing the system can do to prevent him from using the
authority under my instruction. He agreed! So then i said
that if you really want to prevent the authority from escaping,
the proper solution is to put him in a confined box.
- He said that ticket-based capabilities, indeed, might be a
better security model, but that it's just too different from
anything people are used to. On the other hand, POSIX
privileges and IRIX's ACLs were designed such that they could
be added on to the Unix model the way it is now.
My conclusion is that he probably "got it" but that he's not as
enthusiastic about the benefits of capabilities as we are; and he
does think that ACLs and POSIX privileges "can work", so it's okay
to go ahead that way. His colleague said that it sounded "weird"
to be able to define your own security behaviour in terms of object
behaviour -- but he definitely looked interested, and he had an
encouragingly thoughtful expression on his face.
Casey seemed very open-minded and knowledgeable in general; he was
quite happy to argue with me, and even said "hey, we need some
security guys" (when i said, "even though i'd just argue with you?"
he responded "all the better"). He had not heard of EROS, E, or
KeyKOS before. I am planning to send him some references (please
suggest some good ones, and a good way to present them!) At one
point during his talk he mentioned that there exists an A1-level
(mathematically-proven) operating system out there, which surprised
me because i thought that EROS was the only one; he cited SCOMP.
Hmm. Perhaps an implementation of the confused deputy using POSIX
privileges would convince him and the Linux-kernel folk. I don't
know how they would solve the problem starting from where they are
now, though. Maybe it's even impossible without starting over.
So... how to proceed? We have a potentially huge terminology
battle on our hands. I'm guessing that some of you (Jonathan?
Norm?) already know about POSIX 1.e privileges/"capabilities".
Did you know of the extent of the terminology leakage? It would
appear to be more serious now that the Linux people and the SGI
security people are both using this term, and that they seem to be
the only ones really working on a major operating system security
effort in the limelight these days. I think it's important to
stay in touch with Casey.
Do we even need a new word for "capability"?
"Don't worry about people stealing an idea. If it's original, you'll
have to jam it down their throats."
-- Howard Aiken