[cap-talk] Second ABAC - object security, Tyler up

[Jed Donnelley]

<very sad story - I composed some 8 messages in this thread.  When I 
wasn't seeing any
replies I got suspicious and eventually found I lost all those 
messages.  Perhaps you are
spared to get only a very high level summary, but I'm quite 
frustrated and see a great loss>
At 11:47 AM 7/17/2006, Ian G wrote:
>Kenton Varda wrote:
> > Yes, the fact that ABAC is just good object-oriented programming has
> > been pointed out before.
> >
> > I wonder if renaming the whole concept to "object-oriented security"
> > would make it more intuitive.
>
>Ha!  I would definately agree with the spirit of
>this comment :)  Even if someone were to show how
>this wouldn't be right, it would be a helpful
>description.
>
>And, there may be merit in the term, for marketing
>purposes.  "Doing OO security using capabilities..."
>
> > You could describe it as "using encapsulation and data hiding as a
> > secutity mechanism".
> >
> > On 7/17/06, *Julien Couvreur* < julien.couvreur at gmail.com
> > <mailto:julien.couvreur at gmail.com>> wrote:
>...
> >     My suggestion to address this would be to make a parallel with
> >     object-oriented programming.
>
>I'd agree, in that capabilities to me is, in very
>few words, "OO done more tightly, and extended
>out of the language and across net space."

Capabilities can of course be done at the language, OS, and/or 
network levels.  All can be important.  At the language level I agree 
that they are little more than strict OO design.  However, at the OS 
and network levels they are much more.

Capabilities are quite a simple concept - zero based access control 
with communicable permission tokens - whether at the language, OS, or 
network level.

For me the phrase "authority based access control" is an oxymoron and 
doesn't effectively convey anything about the capability model.

I believe the phrase "object based access control" would be much 
superior.  It is a difficult task trying to encapsulate even such a 
simple concept in a few words, but perhaps the greatest difficulty is 
separating it from other concepts (e.g. the prevailing identity based 
ambient authority model).

One can argue that even the Unix/Windows rwx user, group, world 
access control scheme is "object" oriented.  After all one does set 
rwx access on objects (e.g. files).  The important distinction is 
that having set such access, it is set for all processes (active 
objects, running programs) with the identity referred to (user, 
group, world).  In this sense the prevailing paradigm (at the OS 
level anyway) is more identity based that object based.  The 
capability approach is strictly object based.  No authority token 
(capability), no access, and each process (active entity) has it's 
own set of tokens.

I think it unfortunate that neither Alan or Mark really described how 
simple the capability model is.  You have processes (active elements 
running programs), you have objects, and you have communicable tokens 
that enable permissions on objects - that's it.  Processes start with 
no access and receive permissions via capabilities tokens (however 
implemented).

I hope Tyler (next up, right?) can remedy this situation.  I hope he 
can explain the simple capability paradigm and point out how it works at:

1.  The language level (Mark's talk),
2.  The OS level (much of Alan's talk), and
3.  At the network level (hopefully Tyler's talk).

I also hope Tyler can separate out implementation issues - especially 
the fact that capabilities at the network level, while they must 
indeed be represented as bunches of bits, need not be as weak as 
passwords (thought even as simple passwords they can be 
extraordinarily useful - e.g. Amoeba, NLTSS, YURLs and Widewords, etc.), e.g.:

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

I certainly wish I could get an invitation to Tyler's presentation - 
even with a requirement that I keep my mouth shut...

Good luck Tyler!!!

I'm quite sorry that I don't have time now to go back and recreate 
all the detailed comments I made on Mark's talk - which I listened 
through carefully.  I agree with most of the other comments made - 
especially the sense that the academic history shouldn't be 
considered an albatross, but rather a value to draw from - proudly.