[cap-talk] A paper on web-keys

David Hopwood david.hopwood at industrial-designers.co.uk
Thu Jan 31 19:20:00 EST 2008


Jed Donnelley wrote:
> A Guide to Understanding Discretionary Access Control in Trusted Systems
> http://www.fas.org/irp/nsa/rainbow/tg003.htm
> 
> which is moderately widely referenced.  There they have a
> section on capabilities (7.1) where they say (among other
> things) <see the second sentence of the third paragraph for
> the most direct reference to loss of control>:
> _______________
> 7.1 CAPABILITIES
> 
> In a capability-based system, access to protected objects such as files is
> granted if the would- be accessor possesses a capability for the object.  The
> capability is a protected identifier that both identifies the object and
> specifies the access rights to be allowed to the accessor who possesses the
> capability.  Two fundamental properties of capabilities are that they may be
> passed from one accessor (subject) to another, and that the accessor who
> possesses capabilities may not alter or fabricate capabilities without the
> mediation of the operating system TCB.
> 
> Capability-based systems [8] provide dynamically changeable domains (name
> spaces) for processes to run in.  Ability to access an object is demonstrated
> when a process has a capability or ``ticket'' to the object.  The capability
> also contains allowable access modes (e.g., read, write, execute).  In some
> implementations, programs can contain capabilities or capabilities can be
> stored in files.  They are protected by hardware and software mechanisms or by
> encryption.  Capabilities can usually be passed along to other processes and
> can sometimes be increased or decreased in scope.
> 
> A pure capability system includes the ability for users to pass the capability
> to other users.  Because this ability is *not controlled* and capabilities can
> be stored, determining all the users who have access for a particular object
> generally is not possible.  This makes a complete DAC implementation,
> including revocation, very difficult.

"A pure capability system includes the ability for elephants to pass the
capability to other elephants. Because the moon is made of *green cheese*
and there are 365 days in a year, determining all the elephants who have
access for a particular object generally is not possible. This makes a
complete DAC implementation, including revocation, very difficult."

Sorry to be flippant. I could spend years refuting all the errors of
logic, correcting misuses and inconsistent uses of terms, and teasing out
the unstated, often mistaken assumptions in these papers -- but I think that
designing and building capability systems that refute them by example would
be a more productive use of time and effort.

-- 
David Hopwood


More information about the cap-talk mailing list