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

[Jed Donnelley]

<Jonathan, sorry for the attached jpg.  I see
how Mailman handled it reasonably.  Should I (we)
post such graphics separately to the Web and just
include a URL in future?  Anybody interested in
the figure, Table 8.1, can find it in the Mailman
archive at:
http://www.eros-os.org/pipermail/cap-talk/attachments/20080121/1a2a060d/attachment-0001.obj
though of course it's also in MarkM's thesis...>

At 07:44 AM 1/22/2008, Mark Miller wrote:
>On Jan 21, 2008 10:21 PM, Jed Donnelley <capability at webstart.com> wrote:
>...
> >  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.

Whew!  Thanks MarkM.

> >  ...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.

It is a user-mode process with it's own authority
to work with.  The "file server" (e.g. in NLTSS)
is privileged to communicate (and be trusted by)
the disk driver, by which 'process' it has the authority
to read and write the disk.  Still, this is just the
same notion carried another step.  The disk driver in
NLTSS was part of the kernel as were a couple other
"driver"s, such as the 'process' driver (provided
means to create, access, start, stop, etc. processes).
Hmmm.  Now that I think of it I can't remember any
other "driver"s in NLTSS.  The network was handled by
the message system (the TCB that provided the base
communication), so it wasn't considered a "driver".
Any other devices would have had such "driver"s,
but in NLTSS the CPU, disks, and network were really
the only devices.

> >  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.

Ah, perhaps this is why my NLTSS experience made
this concept more difficult for me.  The only thing
the NLTSS TCB provided was the communication between
processes (whether local or network) and the device
drivers.

>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.

Isn't it also true (or perhaps shouldn't I say, 'shouldn't
it also be true?') that even if the TCB does provide something
other than the "invoke" mechanism (and of course the extension
mechanism to enable it), then at least from the perspective
of a user process it should appear that "invoke" is all that
is provided by the TCB?  That is, any capability should be
able to be emulated by the extension mechanism.  If that is
the case, then it should appear from the API that all
capabilities provide only the "invoke" facility.

>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".

For me this feeds into this comment:

> >  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?

I notice you didn't respond to my question
about this definition "trivializing" the
notion of "permission" in object capability
systems.  From my perspective if all one
had to deal with were object capability
systems then I think a better use could be found
for the "permission" term - e.g. exactly what
you refer to as "authority" - except for just
that "authority" which is available through
a specific capability.  A minor point perhaps.

> >  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.

Ain't that the truth.

> >  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.

Whew!  Thanks for helping me through that then.  I'm
sure that after all this I'll not forget the concept,
though my contrary experience might get me to
inadvertently backslide a bit now and then ;-)

>...
>[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.

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