[cap-talk] CapDesk demo, capability demos in general

[Jonathan S. Shapiro]

On Mon, 2007-10-08 at 12:18 +1000, James A. Donald wrote:
> Let us use the metaphor that capabilities are keys, and
> ACLs are membership lists that are checked against IDs.
> Now if there are some activities that we only want one
> particular piece of software to perform, and no other,
> then the restriction functions as an ID, rather than a
> key.  One can always use a key as an ID, just as you
> suggest.  If the trusted software is trusted not to pass
> the key around, no problem - the key reliably identifies
> the software.  Yet a key is *not* an ID because it *can*
> be passed around.  It would not be good practice to
> assume that whosoever can open Joe Bloggs locker is Joe
> Bloggs, but it would be good practice to change the lock
> on Joe Bloggs locker and issue the key to someone
> carrying an ID card that says "Joe Bloggs".

Your reasoning here seems flawed to me.

While capabilities can be passed around, we can presumably trust the
installer to guard itself. If the installer initially holds its
capabilities exclusively, they will remain so. Therefore, I do not see
the potential for capability passing as a particularly relevant issue
here. The possibility of unintended transmission is greatly mitigated by
the requirement for explicit designation of authority.

Concerning the ID issue, I'm not entirely sure what you mean, but I
*think* you are suggesting that the identity of the installer
application (perhaps in the form of a hash of its code) might be
considered a subject for ACL purposes. This is certainly feasible, but I
don't think it addresses the problem. The problem is that an
administrator has sufficient authority to add the administrative subject
to all object ACLs, including those that are intended to be exclusively
held by the installer. The *inability* to make this edit is precisely
what makes capabilities a better solution to this particular problem.
That is: the fact that we can assign an ID to the installer does not
change the fact that the administrator can run around and edit the ACL
lists. The original proposition was that the installer should be able to
hold authorities that the administrator cannot. In capability systems
that can be done. In ACL systems it generally cannot.

Note: I'm not arguing against ACLs broadly here; I just think this
particular use case isn't a good match for them.

Also, I'm ignoring disk editors in all of this.

> The more capabilities are used to protect and manage
> permissions that are large, important, and durable, then
> the more it becomes a problem to protect capabilities,
> the more capabilities are a vulnerability, rather than a
> protection.

Hmm. That statement involves quite a number of assertions. Some I agree
with, some I find questionable.

I certainly agree that large, important, durable permissions are
sensitive things that need to be handled with care.

I agree that *any* permission system can be mishandled, and there are
risks in this. I wouldn't call that a "vulnerability", because I prefer
to use the term "vulnerability" to refer to concretely exploitable
properties rather than unqualified risks. It is certainly a potential
*source* of vulnerability.

In my opinion, there are serious risks with both ACL and capability
designs. The main practical advantages that I see in capability systems
are the ability to front-end (virtualize) authorities, POLA, and the
relative difficulty for hostile code to transmit them promiscuously. The
main practical advantage I see in ACL systems is auditability.

Both systems seem to me to have risks of mismanagement. Subjectively, I
believe that the risks in capability systems are smaller, but this is
something that I do not know how to measure quantitatively.

> But I have been spending some time trying to think how
> to make protected capabilities function so that one
> single kind of protected capabilities addresses all
> problems, and such solutions seem painful to me.

I do not know what you have been thinking about specifically, so I can't
comment in any detail. I only urge you to consider that capabilities are
probably NOT a good end-user-visible solution for many problems.
Mechanism often needs to be built on top of them to make them effective.

One confusion in the capability/MAC debate is that capabilities neither
support nor defeat MAC. Capabilities provide a substrate that can be
used to construct MAC enforcement in higher level software. The
statement that capabilities cannot enforce MAC is narrowly correct, but
it misses the point entirely.

I re-state this point only to remind you to ask the right question. The
right question isn't "are capabilities perfect for my problem", but
rather "do capabilities let me build a solution for my problem".

>   I
> don't think they scale over networks where many people
> whose interests may conflict have control over different
> parts of the network.

I agree, but I don't think *anything* does that. In any case, I believe
that local capabilities and network permissions are qualitatively
dissimilar. The failure domain semantics are very different, and the
ability to control propagation disappears once the permission exits the
relevant TCB.

This is part of why I believe that network permissions should only be
useful within a context imposed by an authenticated session.

And let's be honest: authenticated sessions are the world's coarsest ACL
system.

> To return to our locker analogy, post office boxes are
> on the outside of the building, and whosoever has the
> key can open them, and often the person with the key is
> not the registered owner but someone acting on behalf of
> the registered owner, but safety deposit boxes are on
> the inside of the building, and to open them one needs
> both the key and an identity that matches the list.

Or at least a good ID card machine, but I think I see your point.

>  > The problem with either-or systems is that things slip
>  > through the cracks where (a) the two systems have been
>  > configured in subtly different ways, or (b) the
>  > overlap in what the two systems can express is
>  > imperfect.
> 
> Protocols generally fail at the boundaries and edge
> cases.  But one can only minimize boundaries and edge
> cases, not eliminate them.  The solution is to do the
> boundaries right, not to eliminate them altogether.  The
> solution has to be at least as irregular and complicated
> as the problem.

That point of view is compelling and seductive. Unfortunately, it has
failed universally in the wild. The only thing worse than one inadequate
protection system is *two* inadequate protection systems...

shap