[cap-talk] Definition of "authority"? r.e. technical term for computer systems

[Mark Miller]

On Jan 18, 2008 7:24 PM, Jed Donnelley <jed at nersc.gov> wrote:
> On 1/18/2008 5:54 PM, Karp, Alan H wrote:
> Maybe somebody can point me to some documentation
> that I can read to get up to speed on this?  Perhaps
> there is some place in MarkM's thesis that will help?
> I've looked at the first dozen or so uses of "authori*"
> and I haven't made any progress.

That is very disappointing to hear, but thanks for letting me know.
For more precise and formal analyses of authority, there are Fred's
thesis and Toby's papers, but I don't know that either will help
clarify the issues you are asking about.


> Perhaps this sentence can help:  "In practice, programmers
> control access partially by manipulating the access graph,
> and partially by writing programs whose behavior attenuates
> the authority that flows through them."
>
> This seems to be close to the key.  It sounds suspiciously
> like MarkM's even number writing example:
>
> > I use "authority" to mean the effects one can cause. If Alice has
> > permission to write to file C and Alice gives Bob an object that
> > enables Bob only to cause even numbers to be written to C, then Bob
> > has the authority to cause even numbers to be written to C.
>
> In that case I would say that the object that Alice gave
> to Bob only granted him the "permission" to write even
> numbers into the file.  Not?  Alice clearly didn't give
> Bob permission to write openly to the file.

Let's call the object Alice given to Bob "EvenWriter".

* In an ocap system, Bob has a reference to EvenWriter and EvenWriter
has a reference to C.

* In a conventional Unix-like system, EvenWriter is a process running
with Alice's principal-id, and the ACL-like information associated
with C says that Alice (and therefore EvenWriter) can write to C.
EvenWriter reads commands from a socket, and obeys those commands that
direct it to write even numbers to C. Alice creates that socket and
permits Bob to write to that socket.

In both cases, Alice has given Bob authority to write even numbers to
C. However, if we dump the system's protection state -- the state of
the permissions systems that governs what actions the subjects can
directly take -- we see a snapshot of the access graph/matrix. In an
ocap system, the snapshot is the topology of the reference graph among
the objects. In a Unix-like ACL-like system, we see principal-ids,
files and sockets with owner principals and permission bits (rwx, or
whatever) associated with other principals. In neither case can we
find in this snapshot any representation of Bob's ability to write
even numbers to C. The permissions system itself has no concept of
"writing even numbers", and should not. Therefore, this ability, which
Alice grants to Bob, is not a permission.


> That
> permission, which Alice has, was attenuated - as MarkM
> suggests - so as to result in the reduced ... I would
> say "permission" that Bob was given.  Would others say
> the "authority" (that Bob was given?)?  If so, what
> permission was Bob given?

In the ocap scenario, the permission to speak to EvenWriter. In the
ACL-like scenario, the permission to write to the socket which
EvenWriter is reading. In both cases, if we were to ask a debugging
tool this question, where this tool has access to the system's
protection state, this is the most the tool could say. (Note that
Karger and Herbert have proposed[1] that systems should support such a
tool. Their proposal would not accomplish what they imagine it would
precisely because of this difference.)


> Sorry for the struggle.  I just don't seem to be getting
> it.  MarkM suggests that Chapter 8 in his thesis focuses
> on this topic.

Thanks for struggling. Chapter 8 is indeed the key. I myself am
struggling to figure out what more I can say than what I've said in
the thesis -- sorry. All the points I make above regarding even
EvenWriter are entirely parallel to points in Chapters 8 and 9 of the
thesis regarding the Caretaker -- even including the points about
Karger and Herbert.


> (soldiering on...)  Perhaps this will get to the nut of
> the issue.  In Chapter 8 in MarkM's thesis he goes through
> a discussion as above and ultimately makes this statement:
>
> "As our description ascends levels of abstraction, the
> authority manipulated by the extensions of one level
> becomes the permissions manipulated by the primitives
> of the next higher platform.  Permission is relative to
> a frame of reference.  Authority is invariant."
>
> Whew.  I believe if I could understand the above sentence
> I might be able to 'get' this distinction between permission
> and authority.

If an EvenWriterMaker were provided by a library, then the underlying
system as extended by this library could be described as a new
permission system in which Alice does give Bob permission to write
even numbers to C. How we describe Bob's permissions depends on what
we take to be the boundary between the permissions systems governing
the interaction of the subjects vs the subjects that are governed by
this system: Is an EvenWriter above or below this boundary? However,
even as we shift this boundary, as long as Alice, Bob, and C are still
subjects above this boundary, the description of the authority Alice
gives to Bob for affecting C remains constant.

Again, I may simply be repeating myself. If this isn't helping, I'm
not sure what more I can say.


[1] P. A. Karger and A. J. Herbert. An Augmented Capability Architecture to
Support Lattice Security and Traceability of Access. In Proc. 1984 IEEE
Symposium on Security and Privacy, pages 2–12, Oakland, CA, April 1984.
IEEE.

-- 
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM