[cap-talk] Capabilities - the rub
eric at theeric.com
Fri Nov 10 12:05:18 CST 2006
On Thu, 9 Nov 2006 22:34:55 -0800
John Carlson <john.carlson3 at sbcglobal.net> wrote:
> On Nov 9, 2006, at 9:12 PM, Mark S. Miller wrote:
> > What's an account?
> Something that gives you the capability to use the capability
> infrastructure kernel.
> An account is all the capabilities that the user has access to that
> you care about.
> If that's only one capability, as I was suggesting then things are
> easy. But I don't
> think that would be a very secure system in most people's minds.
> Thus, I want
> to find out more about the supervisory thing.
As I understand it, Jed's scenario is as follows.
Suppose I want you to have access to my system, but I wish to be able
to revoke it at any time. Therefore, I give you a revocable capability.
The question is this: Is there any action that you can do to my system
via that capability that would allow you to retain access in the event
that the capability is revoked?
You might employ social engineering; you could attempt to manipulate the
other users on my system into revealing their secrets to you. But this
is a weakness in any secured system, and is not specific to
You might scrutinize the object behind the capability: the proxy which
I created for you, in an attempt to find a weakness, a way to induce it
to misbehave when I give it the "revoke" command. But this is exactly
the same process that leads to compromises in other secured systems;
by exploiting bugs in privileged objects, such as the kernel or a suid
program. In this case, the privileged object is the proxy, but the
principle (and the defenses) are exactly the same.
You might look for an error that I, as the administrator of my system,
made when I was setting up your environment, that may allow you to
escalate your privileges beyond what I intended. An example of this
in Unix systems would be having the shadow password file world-
accessible. A roughly analogous error in a capability-based system
would be allowing a revocable user to access the system's
What I mean by "supervisory capacity" is this: the ability to monitor,
modify, and/or block any request or response between two communicating
entities, and the knowledge that any communication between those entities
must be subject to that ability.
Considering that that is what an operation system kernel does, it should
not be surprising that if we construct a secure object to do exactly the
same thing, it is capable of enforcing the same level of security. But
somehow, it is.
More information about the cap-talk