[cap-talk] Confused Deputies in Capability Systems

[Toby Murray]

On Sat, 2009-02-07 at 16:28 -0800, Bill Frantz wrote:
> toby.murray at comlab.ox.ac.uk (Toby Murray) on Saturday, February 7, 2009 wrote:
> 
> >Credentials are issued by specific Security Authorities. You ask your
> >Security Authiryty "is this credential valid?", so the SA acts like an
> >auditor.
> 
> I'm trying to map this description onto the capability systems I know well.
> Let's consider Joe-E and CapROS. In Joe-E, a capability (object reference)
> is created by "new" and consists of a protected pointer. In CapROS, a
> capability is created by the space bank or by the (process) builder and
> consists of a protected data structure which designates the object and
> describes the basic access rights to that object.
> 
> I don't quite see how to map the auditor, or the question, "Is this
> credential valid?"

Suppose a service is invoked by a client, c, with a message containing a
capability, Cred, supposedly to a credential object. Cred could have
been created in many different ways -- the client, c, could have
manufactured it itself from its own space bank (which is presumably
separate from that of the service) or the client may have been issued it
when it was first created. If it is manufactured from the client's space
bank, the service has no guarantee that the object (i.e. process) that
Cred designates will behave as it should -- i.e. by correctly reporting
the user's security clearance.

The service relies only on credentials issued by its Security Authority.
It has a capability, SA, to the security authority that it can use to
find out whether other capabilities designate valid credentials -- i.e.
the service can do
SA.isValidCredential(Cred)
to find out whether Cred designates an authentic credential.



> A confused deputy occurs when the access check is performed for the wrong
> subject. In the network interface case, the access check was for the
> correct subject, the interface had access to all the TCP connections, and
> was trying (and failing) to narrow that access down to one particular
> connection. In the classic compiler case, the access check should have been
> performed with the user as subject, but because the open was performed by
> the compiler, the check used the compiler as subject instead.

This is yet another way to characterise confused deputies. I'll respond
in a new thread by collecting the various definitions together to see if
we can distill out the common parts.