[cap-talk] Comprehensive Security Policies on Capability Systems

[Jed Donnelley]

At 09:04 AM 1/16/2007, David Hopwood wrote:
>Toby Murray wrote:
> > On Tue, 2007-01-16 at 02:03 +0000, David Hopwood wrote:
> >>Toby Murray wrote:
> >>
> >>>Here "Bob-as-employee" is a role, available to user Bob. Bob may have
> >>>other roles he can assume too, in which case he'd have capabilities to
> >>>other membranes that represent these roles as well.
> >>>
> >>>One could enhance it by having the membrane for role X disallow any caps
> >>>to traverse it that have already passed through the membrane for another
> >>>role Y. The idea would be to prevent Bob from using caps obtained in
> >>>role X while acting in role Y, [...]
> >>
> >>Why would we want to do that?
> >
> > To prevent powers obtained in one role from being (ab)used while acting
> > in another role.
> >
> > For example, Bob may have two roles. He might have access to certain
> > powers in his Bob-as-programmer role, but might also have access to
> > other powers in his Bob-as-security-custodian role. The powers from
> > these two roles logically should not be mixed.
>
>This is an additional policy constraint that is not implied by the use of
>RBAC in general. It is an anti-delegation policy: if Bob-as-programmer
>has a power, then why should he not be able to easily delegate that power
>to Bob-as-security-custodian, or vice-versa?

I'm sorry if I'm jumping in here a bit out of context, but I believe 
the mechanisms
that we've worked out recently for delegating responsibility (Horton) work just
as well for role based access control as they do for identity based access
control - and there is nothing "anti-delegation" about them.  That is, they are
pure capability and always faithful to the inalienable right to delegate where
communication is possible.

I believe I understand David's concerns and the resolution.  With the mechanism
like Horton, access is delegated through a capability (object) labeled with the
appropriate identity or role.  By doing so any subject with "upstream" control
can turn on or off permissions by label (e.g. identity or role) - 
think of it as
control being exercised through a membrane.

Any active object with any such capability is still free to communicate such
a capability directly for needed delegation.  Such directly delegated 
capabilities
are "managed" upstream together.  That is, there's no "identity" or "role"
identification associated with a specific active object (process) 
trying to access
them, but rather the binding to a role or identity is in the 
capability itself and is
bound at the time the "responsibility" is delegated.

All this:

>For example, suppose that the security configuration for a database used
>by Bob's programming project needs to be set up. This may require powers
>from both the Bob-as-programmer and Bob-as-security-custodian roles: either
>
>  - Bob-as-programmer delegates the ability to set the security configuration
>    on the database he created to Bob-as-security-custodian, or
>  - Bob-as-security-custodian delegates some subset of his security-setting
>    powers to Bob-as-programmer.
>
>(probably the former would be better, but only Bob can decide that).
>
>There may also be cases where one role can be usefully modelled as a subrole
>of another; for example, Bob-as-project-X-programmer could be a subrole of
>Bob-as-programmer.

Is of course trivially (a simple matter of management on Bob's part) doable
with such a scheme.

Regarding:

> > The intent behind adding this restriction is to make it less likely that
> > Bob will use a power in the incorrect context.
>
>What is an "incorrect" context is a subjective value judgement, unlikely
>to be predictable in advance by some central authority. I think that such
>a restriction is unlikely to improve security, and may prevent Bob from
>properly getting legitimate work done (which would act as a disincentive
>to him using roles as intended).

Hmmm.  I don't agree.  I can see how Bob might want to grant some of his
Bob-as-programmer role based permissions to some applications and
some of his Bob-as-security-custodian permissions to others.

If at a later time it was determined that the programmer role needed
additional authority, that could be granted upstream and Bob's programmer
role application would continue to function with the new authority.

Similarly, if Bob was changing roles and responsibly (with identity)
delegated some or all of his Bob-as-security-custodian privileges to
Mary-as-security-custodian, then Mary could continue to carry
out the security-custodian role with appropriate increased or
decreased privileges as needed and authorized for that role
(upstream) - again still with the pure capability facility for
direct delegation following any communication path.  Bob's
Bob-as-security-custodian capabilities would become invalid, but
Mary's permissions responsibly delegated from Bob would continue
to function (via upstream control through the label that was
appropriately tied to an "identity" that only Mary could exercise).

>I do not dispute, BTW, that Bob should have to *explicitly* delegate powers
>between roles. However, I question whether this needs any additional
>elaborate mechanism. Users should also be able to explicitly delegate
>powers to other users, so the system can for the most part treat roles
>just as it would treat users, perhaps with some minor user interface
>differences.

I believe the issue is the upstream (of the delegation) control that allows
capabilities in place for specific identities or roles to be adapted as
needed.  We had quite a lot of discussion of this on the various threads
related to this topic, but I can certainly understand that it won't be clear
at least until we get a paper out there clarifying it all in a cohesive
package.  Unfortunately much of my time is being drawn away for
some consulting.  I hope I'm able to find time to keep that write-up
progressing.  Naturally others are welcome to help.  My only concern
is that the basic concepts and mechanisms get effectively described.

> > It also makes analysis easier by ruling out avenues for unintended
> > rights-amplification. When analysing the powers available to role X, we
> > don't need to be concerned with what other powers might be available in
> > other roles, that if used in combination with powers from role X could
> > allow the user to perform some sort of rights-amplification, thereby
> > exceeding the authority-bounds imposed upon their role by the security
> > policy.
>
>I don't see that as a particularly serious issue. The "setting the
>security configuration of a database" example *depends on* Bob being able
>to use powers from two of his roles together, quite legitimately. I would
>expect such examples to be very common.

And they can be services as discussed above.

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