[cap-talk] In Defense of Identities - proxying, more on the nuisance factor

[Jed at Webstart]

At 05:35 AM 12/5/2006, Jonathan S. Shapiro wrote:
>I have watched the discussion under "tracking responsibility" with some
>interest -- not least because I've been looking at how to put up a
>collaboration environment for The EROS Group, and many of the serious
>difficulties boil down to issues of identity management. I want to make
>a case here in defense of identity-based controls.
>
>Let me first qualify that: I do not propose that identity based controls
>should replace capabilities. Capabilities provide a form of positive
>authorization that is exceptionally useful and important for narrowing
>authority, and I do not propose to change that. However, I think that it
>would be useful to look again at the role of identities for
>authorization.
>
>I am contemplating here a system similar to SCAP, wherein capabilities
>are necessary but not sufficient, and identity-based authorization is
>additionally required.

Glug.  If a capability isn't sufficient and I want to delegate a permission
(effectively a parameter that I was passed and now want to pass on
for modular OO programming), how do I do it?  If some sort of identity
authorization is also needed then I need some way to effectively
say, "I - who have permission to access this resource - wish to
delegate access to this other identity so that it can act on my behalf".
At that point I just have a more complex implementation of
capability communication.

>I (of all people) understand why this is messy from any purist
>perspective, but I want to go back to one of our core arguments, because
>I suspect that it is technically correct and pragmatically irrelevant.
>
>We have argued from a purist perspective that identity-based controls
>are meaningless, largely because they cannot preclude proxying.

I don't consider there to be anything "purist" about my argument in
favor of being able to delegate permissions (which is all I see a
'capability' as - whether implemented as descriptors, encrypted
capabilities as data or even using an identity based ACL
mechanism).  Being able to delegate is absolutely fundamental
(in addition to being impossible to block).  It's needed for any
sort of modular programming or even for effective human
interactions.

I think this discussion is timely as I see it as tying into the work
that I'm doing with Mark Miller (and any others interested) on
responsibility tracking.

>First, I want to note that there are two distinct types of proxying:
>human proxying and software proxying. By human proxying, I mean proxying
>wherein some explicit human action is required to enable the
>communication channel. Three examples of human proxying:
>
>   1. Alice leaves a group, but asks Bob (who is still in the group) to
>      answer some question. Bob does.
>
>   2. Alice leaves a group, but asks Bob for access to something. Bob
>      grants Alice a proxy, whereupon Alice uses it.
>
>   3. Alice leaves a group, but asks Bob for access. The two parties
>      conspire to build a proxy that communicates using covert channels.
>
>The first case cannot be prevented computationally. In an ACL system,
>the second *can* be prevented -- at least to the extent that an
>administrator can restrict cross-user invocations to invocations on
>administratively authorized subsystems. The third cannot be prevented by
>any technique I know about, but it has a high enough engineering and
>expertise cost that it ranks fairly low in the threat space.

Perhaps I need some more details on the above.  I don't see a particularly
high engineering and expertise cost to #3 - naturally if it's done once and
shared.  Also, if every time Bob tries #2 his request gets blocked then
of course he'll be interested in something like #3 to get his work done.

>Software proxying relies on the installation of a Trojan horse, such
>that software acting with Bob's authority conspires independent of Bob's
>intent.

This intent issue is important.  Was it Bob's intent to grant Alice the
permission that Alice requested?  If so and such a delegation was
appropriate policy as Bob understands it (with Bob's local knowledge),
then Bob should be able to grant Alice the desired permission.
Wouldn't it help if Bob could do so with identity tracking so he could
protect himself as much as possible - e.g. with a possible future
revocation and with responsibility tracking?

>What I want to point out here is that from a threat model perspective,
>absolute success in preventing conspiracy between Alice and Bob must be
>considered a threat, not an objective.
>
>Why?
>
>Consider the signoff structure in a business. On a significant expense,
>it is customary that two levels of management must sign off. Inevitably
>one of those levels is traveling and delegates their signoff. This is a
>situation where the overt rules are compromised to the objectives.

Is such delegation allowed or not?  Who decides?  As you've seen I
argue that anybody (process) with the permission needs to be able
and should be able to delegate it to any person (process) that they
can communicate with - without requiring a superuser or even the
"owner" of the resource to do so.

>Even in military contexts, there is some degree of local discretion
>about disclosure under combat conditions. The system relies on the
>trustworthiness of the participants to make judgments in the field.

There needs to be.  Local knowledge.  Once you've trusted a subject
with a permission, well, you've trusted them with a permission.  You
necessarily have to hope that their intent is good.  You may be able
to help them notice unintentional policy violations, but you can't stop
them from violating policies with a permission they have.

>The question I am exploring is whether *all* conspiracy guards shouldn't
>be viewed this way. That is, anti-human-conspiracy rules may all have an
>exception, and if so our goal isn't to make them impossible; it's to
>make them a sufficient nuisance.

We don't want to raise the nuisance level for legitimate delegations.
In fact it's vital that we not.  Making such delegations easy and
convenient is the only hope we have for achieving POLA - which
I think you will agree itself has value in this security/access control
space.

>Perhaps the purpose of identity-based
>controls is to set a high market price on conspiracy, not to prevent it.

Grumble.  Set a high price on conspiracy at the cost of setting a high
price on legitimate collaboration?  Do that and Lampson continues to
be right and Microsoft's first law continues to apply.

>In such a model, don't identity-based controls serve a valid purpose?

Identity tracking I say yes.  Identity controls (requiring third party
management of identity based ACLs) I say definitely NO.