[cap-talk] Architectural Choices for Security: terminology

[Jed Donnelley]

At 07:52 PM 11/18/2007, David Hopwood wrote:
>Jed Donnelley wrote:
> > It seems to me that another distinction that is rolling around
> > in here is the ability or non ability to delegate.  For me that
> > is the fundamental aspect of a "capability" system.
>
>Nope. Non-capability systems that support impersonation (e.g.
>Windows NT) provide the ability to delegate. They do so in an
>extremely dangerous and error-prone way -- so much so that it is
>probably not a good idea to ever use this mechanism -- but they
>do provide it. Even Unix 'setuid/setgid' provide some ability to
>delegate.

By delegate I meant delegate individual permissions (to
whatever level permissions are controlled), not identities
for ambient authority or any other sort of forced group/bundled
permission set.  Sorry if I wasn't clear about that.

>In an IBAC system, whether a request succeeds is dependent on the
>requesting subject. That holds regardless of differences between
>systems as to which properties of a subject are tested.

As I argued in Managing Domains:

http://www.webstart.com/jed/papers/Managing-Domains/#s10

I believe you can get the effect of a capability system
(functional effect) with an ACL-based implementation.
The basic idea is to set up a protocol where any
process with a permission can add any other process
that it can communicate with to the ACL for that
permission in such a way that the process being
added (as it finds out in a message) can know that
the "sending" process had the message originally.

>In a cap system, whether a given request succeeds it is not dependent
>on the requesting subject at all. Different subjects are distinguished
>by being able to send different messages, and it is only the message
>contents that determine what happens.

I believe the above is a characterization in terms of an
implementation type, not necessarily in terms of the
base functionality.

E.g. consider the DCCS.  While from the viewpoint of
the processes involved the DCCS presents a pure
descriptor type capability communication system,
at the level of access control between the 'host'
processes (vat support?) the DCCS uses an access control
list mechanism.  Push that mechanism down to the level
of individual processes and you have an ACL implementation
with capability semantics (just another way to
approach the same basic mechanism).

Maybe this isn't a discussion that is likely to be
effective on the cap-talk list?  If I have time at
some point perhaps I can bring it up at one of the
HP meetings.  If I get down there, though, I first
have more important fish to fry (capabilities as
data with confinement - e.g. for the 'CapBrowser'
work I want to do).

--Jed  http://www.webstart.com/jed-signature.html