[cap-talk] The Hurd and Capabilities

[Neal H. Walfield]

At Thu, 10 Aug 2006 11:51:13 -0700,
Jed at Webstart wrote:
> 
> At 03:06 AM 8/10/2006, Neal H. Walfield wrote:
> >At Wed, 02 Aug 2006 17:20:09 -0700,
> >Jed at Webstart wrote:
> >Mach supported
> >network transparent IPC and there is no Hurd policy from preventing
> >such a mechanism from being reintroduced.
> 
> Heh.  Can we map (translate, convert, whatever) YURLs to Mach ports?

According to http://www.waterken.com/dev/YURL/Definition/:

  Enforcing the y-property depends on the features of the identifier
  for the introduced site. . . . To enforce the y-property, the
  identifier MUST provide enough information to: locate the target
  site; authenticate the target site; and, if required, establish a
  private communication channel with the target site.

Mach ports are kernel objects named by protected capabilities,
i.e. capability names are local to a C-space.  They can only be
transferred as part of a message's payload.

If Alice wants Bob to interact with Carol, Alice need only send a
message to Bob containing a capability naming Carol.  This satisfies
the locating requirement.  Since Bob relies on Alice to make the
introduction, Bob can be sure that any invocations he makes on the
capability which Alice passed him will go to the target which Alice
intended.  I think this satisfies the authentication requirement.

I'm not sure how proxies would change this scenario.  That is, if
Alice does not have a direct connection to Bob or Carol.  This is a
question of how Alice was introduced.  If ease dropping is a concern,
I think a man in the middle attack could be overcome using
cryptography.

> > > Is there a general summary of capabilities in the Hurd somewhere?
> >
> >I, in conjunction with Marcus Brinkmann, am currently writing a
> >critique of the Hurd's architecture.  My question was spurned from
> >this effort.
> 
> Huh?  Can you elaborate on the above "spurn"ing?

Interesting mistake.  It should read its antonym: spurred.

Marcus and I are working on a paper and I wanted to clarify the
meaning of facets.

> >On of the forming goal of the Hurd was to build a system which
> >improved ease of use.  Unix mechanisms, it was observed, often imposed
> >arbitrary policies.  Why can't users create their own file systems,
> >for instance?
> 
> Or even create their own groups!!!  That's one aspect of Unix access
> control that's so absurd to me that I can't understand why the world
> doesn't scream about it.  If you have a simple mechanism for bags
> of named capabilities (object access/references), a "directory", then
> you naturally get a directed graph mechanism that can be used
> quite effectively for general sharing.  "Group" sharing is accomplished
> by creating a directory, giving it to others, and then putting shared
> objects (capabilities) into it (e.g. see:
> 
> https://wideword.net/doc/i%2Bej6NZzbDWtc2k444Nk%2FQ%3D%3D
> 
> ).

Although we don't have such a mechanism currently available, I think
it would be quite easy to implement this.  Indeed, I think it is for
the most part just a "natural" use of the Hurd mechanisms.

But I think you could approximate this on Unix as well using
cryptographic hashes.  Create a directory without read permission
(e.g. foo) and place in it one directory for each group with a secure
name (e.g. foo/45adf8uasdflkj).  Give the path name to these
directories to those with whom you want to share.

> >The question the Hurd designers tried to answer was:
> >how can we eliminate the inconvenient policies from the mechanisms?
> >Fine grained objects and virtualizable interfaces were the answer they
> >came up with.
> 
> Sounds perfect.  Then if you can communicate access to such
> objects (permission to access an object, a "capability" to the object)
> then you have the capability model.
> 
> For me the main issue is how such an underlying mechanism bubbles
> up to the human user through all the libraries and especially the
> applications and their built on Unix orientation.  (I appreciate
> the cap desk contribution...).

We use a "fat" C library.  The POSIX mechanisms are built on top of
Mach and Hurd mechanisms.  Many applications don't need to be modified
at all to take advantage of most of the relevant Hurd features, e.g.
the C library transparently wraps the VFS.  Applications can be
modified to take advantage of Hurd features.  Because POSIX is just a
thin layer, this can often be done with little effort.  To get access
to additional Hurd features, there are a number of utilty programs for
e.g. attaching a file system to the VFS.

> >This conception of security
> >contrasts itself quite sharply with security as information flow
> >control policy.  His experiences accrued during the 80s and the very
> >start of the 90s informed the case studies used in designing and
> >evaluating the Hurd and likely did not include malicious threats.
> 
> Who "his"?   (regarding "malicious threats" - see above minimal risk).

This is supposed to refer to Bushnell, one of the Hurd's two main
architects and the author of the cited paper.  I remove a sentence
which left this dangling antecedent.


Neal