[cap-talk] Definition of "authority"? Got it right?

[Mark Miller]

On Jan 21, 2008 10:21 PM, Jed Donnelley <capability at webstart.com> wrote:
>  A subject's "permissions" are what it can get the
>  Trusted Control Block to do on it's behalf
>  (e.g. Bob's communication, Alice's file writing).

Ignoring the issue of what TCB stands for, yes.


>  A subject's "authority" is what it can get
>  other programs to do on its behalf by exercising
>  its permissions.

A subject's authority includes "what it can get other programs to do
on its behalf by exercising its permissions.". But a subject's
authority also includes its permissions.


>  Since this is such a radically different way
>  of stating things, I guess I should wait for
>  a response from MarkM or others.

Clearly you've got the gist. Your text above captures in what way a
subject's authority exceeds its permissions.


>  I think one thing that has been confusing me
>  is that, for example, in the above quote from
>  section 8.1, it discusses Bob's "permission"
>  to talk to Alice, but Alice's "permission" to
>  write to the file - a higher level concept
>  in my thinking.  I tend to always think of
>  file access being provided by the "file
>  server" (NLTSS habit I'm afraid). In such
>  a case MarkM (I believe) would say that Alice
>  has permission to talk to the file server
>  and only the "authority" to write to
>  the file (check me again - I believe now
>  that is right), as the action of writing
>  to the file requires the active participation
>  of the File Server (rather than just the TCB).
>
>  Right so far?

As far as the TCB is concerned, is the file server just another
user-mode process outside the TCB? If so, then yes.



>  What bothers me about this definition
>  set is that, at least for object
>  capability systems, it seems to
>  somewhat trivialize the notion of
>  a "permission".  Permissions are
>  always the same.  They only provide
>  communication.

In all ocap systems of which I'm aware, both language and OS, the
kernel does provide some object types primitively -- such as an
indexable read/write data container of some sort. E provides
FlexLists. The KeyKOS line provides segments and nodes. The
Bishop/Snyder take-grant analysis and Shap's adaptation of this
analysis to reason about confinement in EROS (aka CapROS) took
advantage of this by choosing to treat, for example, read permission
to a segment or node as a distinct type of permission  which they
recognize. However, all capabilities enabling communications with
non-TCB processes were treated generically, as providing only
permission to communicate.

I will now explicit my slight of hand in the paragraph above. Note
where I said "kernel" and where I said "TCB". The EROS Space Bank is a
user-mode process outside the kernel. But virtually everything else in
the system depends on its correctness, so it is justified to include
it in the TCB. Shap choose to do so in his analysis, and so raised the
level of abstraction of his description, so that facets of the space
bank were described as permissions. This is an example of "permissions
are relative to a frame of reference".


>  The real semantics
>  of what a capability allows a
>  subject to do (e.g. a capability
>  to "write" to a file, a capability
>  to 'stop' a process, a capability
>  to 'read' from a keyboard, etc.,
>  etc.) by this set of definitions
>  isn't the "permission" of the
>  capability but rather the "authority".

Yes.


>  Doesn't this seem to trivialize
>  the "permission" notion where the
>  permissions are always the same?
>  Perhaps it is more useful in systems
>  with richer TCBs?

I hesitate to use "richer" for more complex ;). But yes. Most access
control analysis has indeed assumed more complex TCBs. Most OSes
provide more complex TCBs.


>  When I think of "access rights" (e.g.
>  "write" access to a file), in capability
>  systems, they exist in the "data" of
>  the capability (something delivered
>  to the server/object when an invocation
>  happens).  This is what I've tended
>  to think of as a "permission".  Of
>  course that notion is at odds with
>  MarkM's definition that only gets to
>  the TCB level.  The only "permission"
>  that a subject would have is the ability
>  to deliver any such "access bits" (e.g.
>  capability data) to the server (object).

Except for TCB-provided objects, yes. The subtext of all this, which
you also are getting, is that we should stop obsessing about
permission and focus on authority. Authority is what matters.
Historically, permissions have been the lamppost: the key isn't there,
but the light of formal analysis shines brighter. Many of the damaging
myths are founded in this misdirection of attention.



>  I suppose then that something like "access
>  right"s in a capability might be referred
>  to as "authorities" because they are provided
>  by the action of the object (server
>  process)?

Yes.


>  Oh well, they're just words.  I hope I've
>  finally gotten it right.  Of course MarkM
>  goes on to define a whole set of permission
>  and authority notions:
[Table 8.1]
>  that still puzzle me some, but I think I won't go
>  there in this message.  Maybe for a face to face
>  discussion some time.

I look forward to it.


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

    Cheers,
    --MarkM