Capbility Concepts

Al Gilman asgilman@iamdigex.net
Sun, 16 Jul 2000 12:20:37 -0400


At 10:26 AM 2000-07-16 -0400, Jonathan S. Shapiro wrote:
>> NH> I think that we agree that all sucessful capability systems "bottom
>> NH> out" in capabilities as names.
>>
>> Hmm, how does that go together with, say, password capabilities? They
>> consist of a UID and a password. The UID take by itself names an object.
>>
>> Or am I missing something?
>
>A password capability system doesn't bottom out in the way that Norm
>describes, because the operating system itself cannot be bootstrapped
>without either (a) some set of available bootstrap password(s) or (b) some
>other means to load code.
>
>Jonathan
>

This relates to a perplexity occurring in the Grid Forum at present.  The
open issue there could be described as to compare and contrast what
information about an individual person is served from a persistent
information service [likely LDAP] as compared with what information is
involved in the process where that individual demonstrates that their
requests for service from allied administrative domains should be honored.

As I see their scenario, the "system" that operates Grid Jobs doesn't
bottom out into one space of known or trusted identities.  The sharing
trust-space doesn't go to the bottom.  It is layered over multiple bottoms
that are not shared.  In this situation, I see no way to unify the identity
that gets you trusted in a foreign domain with the name that unifies your
identities in all domains.  That would require qualifying lots of people
into a universally trusted administrative domain and that probably won't
happen.

Actually, my naive view of how systems get bootstrapped is similar.  Access
protection is not functioning until after some trusted kernel of code is
loaded.  Then root defines a password and installs the control that makes
loading check with the authorizing function, and further loading requires
authorization.  You can build access control into a boot ROM but the secret
this is built on is static.  Once the access key is compromised, that
system is no longer trustable. 

In the present scenario the system is not trustable until locked.  In the
hardwired situation it is not trustable after compromise.

Let me get to my bottom line with capabilities and Grid Forum.  I suspect
that the Grid Forum would resolve its perplexities better if it had looked
at the situation with the fresh eyes of a "capabilities perspective" first.
 Not that they wouldn't use the existing security infrastructure in the
several administrative domains as the foundation in building a more unified
metaprogramming capability.  But I can't explain the new perspective, and
the likelihood is that they would blow it off as "too theoretical and
exploratory" and hence off-topic.  They are looking at minimal incremental
tweaks to the best current practice that will unify operations across the
allied domains.  Rough consensus and running code is the religion.  To
explain why they should care about this theory, it will take a proponent
better versed than I.  The grid forum can be found starting at
www.gridforum.org.  The issue I described above is actually up for grabs in
this community.  Is there anyone versed in the 'capabilities' perspective
on security that would care to get engaged in this process?

Al