[cap-talk] "Who" seen as thorny (was: Defense of Identities, etc.)

[Jed at Webstart]

At 04:11 PM 12/8/2006, Jonathan S. Shapiro wrote:
>On Fri, 2006-12-08 at 14:33 -0800, Jed at Webstart wrote:
> > At 10:01 AM 12/7/2006, Karp, Alan H wrote:
> > >Jonathan S. Shapiro wrote:
> > >
> > > > Which brings me back to my earlier statement that defining what
> > > > constitutes a "who" is a very thorny problem.
> > >
> > >Indeed it is.  In the e-speak product "who" was defined by knowledge of
> > >a private key.  In Client Utility, "who" was defined by a Protection
> > >Domain.
> >
> > Is there more to this "who" (identity) issue that I'm missing....
>
>Yes, there is, and Alan is not addressing my point either.
>
>The only reason to speak of "who" in a system is when we are trying to
>attribute actions to stakeholders. Unfortunately, actions are not
>performed by stakeholders. Actions are performed by programs. While a
>program may run as a consequence of some command or action that I (the
>human who is logged in) initiate, it does not follow that the program
>acts in accordance with my intent, and it is (generally) absurd to
>imagine that I (the human who is logged in) have any meaningful degree
>of control over the actions of that program.

So far I'm with you.

>A strong argument can be made that if we are looking for a human whose
>intent the program obeys, it is much more likely to be the developer
>than the user. This is true for "well behaved" programs, but it very
>painfully true for programs like viruses and Trojan horses.
>
>So the problem here is that if we are going to make any meaningful
>authorization or logging decisions tied to "who", we need to get all of
>the relevant who's captured in some form.
>
>Based on the general quality level of software in the wild, if the
>program actually *does* do what the logged in human intended, it's
>probably fair to characterize that as fortuitous accident rather than
>developer intent. :-)
>
>Part of what I'm saying is that the term "subject" is different from the
>term "user" for a reason, and it often proves that when we are speaking
>of "who" what we really need is subject ids rather than user ids.
>
>In any case, this is what I was talking about. The definition of "who"
>is deeply complicated because the people who speak of tracing or
>authorizing "who"s generally are being very sloppy in asserting what
>they are really trying to accomplish in the way of traceability. For
>what they really want, tracing the logged in human isn't even CLOSE to
>good enough.
>
>Also, it should now be clear why "holders of cryptographic keys" is a
>useful metric in some contexts, but does not shed light on the problem
>of who is [a] who.

I follow what you are saying.  However, I don't think the situation is
as bleak as you suggest.  While some arbitrary notion of perfection
might be "deeply complicated", I believe we can do quite a good job
of tracking "who" by rather simple means.

With the mechanism we've been discussing for responsibility
tracking in delegations, I've suggested a policy where permissions
are delegated with responsibility and revocation whenever:

1.  They are communicated from one person to another, and

2.  Whenever they are communicated to a newly started program.

This policy approach leaves open how much (if any) labeled
delegation happens between programs (e.g. active objects,
between processes in a single system, across the network).
The default for delegation to people would be that such delegations
last until explicitly revoked.  The default for programs is that such
delegations are revoked after the program terminates (or is
stopped).

Even with just the above I believe we have sufficient tools
for at least quite good logging/auditing and pretty good Trojan
horse protection.  I'm assuming of course POLA delegation
between both the people and programs that follow policy -
i.e. the "good guys".

A "shell" (power box, whatever you want to call the software
that launches programs for people) can create a unique
identifier (or even a human readable string - a performance
trade-off) that can be used in the delegation labels for
permissions passed to programs that it runs.  I'm not sure
just what sort of label would be best.  Perhaps the path
name to the file?  Maybe include an MD5sum?

In any case with such an approach every exercised permission
can be traced to a delegation track of any people and at
least the first level of programs that exercise the permission
(invoke the capability).

 From my perspective any program that is run can be viewed
as an individual product.  It may trace various aspects of it's
creation (responsibility) to any number of people, organizations,
etc.  However, from the perspective of responsibility tracking it
can be viewed as a single entity.  Of course a running program
can have very complex linkages - static, dynamic, and network.
Still, I think it's reasonably safe to leave the trade-off as to whether
to do further labeled delegation (for placing any 'blame' elsewhere)
up to the program.

Is that still insufficient for your needs?  If not perhaps you can
describe what you feel is still missing.

Thanks for taking up this topic.  It's quite relevant to the work
we're doing on delegating responsibility.

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