[cap-talk] The Hurd and Capabilities

[Jed at Webstart]

At 03:06 AM 8/10/2006, Neal H. Walfield wrote:
>At Wed, 02 Aug 2006 17:20:09 -0700,
>Jed at Webstart wrote:
> > Regarding the Hurd and capabilities - has anybody done a network
> > extension of capabilities for the Hurd?  Nobody on this should be
> > surprised to hear me say that I believe such an extension should
> > be written and tested before any Hurd capability mechanism is
> > "finalized".  If it has been done I'd be very interested to hear how it
> > went.  If not I'd like to know why not.
>
>The Hurd, in its current form, runs on top of Mach and uses Mach's
>ports as the basis of its capability framework.

I see.

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

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

>Since you're interested, I will forward you the document
>as it approaches a more finalized form.

Thanks.  I am interested.  My interest is mostly in regard to
any chance to get wider spread for the object model of
access control (communicable "capabilities" to objects).

> > Does anybody believe the Hurd has a chance to be a capability base
> > to build from that many of us are looking for (why or why not?)?
>
>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

).

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

>Security is mentioned as an important goal [1]: neither programs nor
>users should be able to harm each other.

Is there ever any mention of the Principle Of Least Authority
in Hurd design discussions?  This goes a bit beyond requiring
that neither programs or users can harm each other.  It further
suggests that both programs and users should be able to
get services performed for them with minimal risk.  They
should be able to protect themselves when they need to
share some of their permissions, but not all.

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

> > I'd particularly like to know how far this statement goes:
> > (from: http://www.gnu.org/software/hurd/hurd.html ):
> >
> > it's compatible
> >      The Hurd provides a familiar programming and user environment.
> > For all intents and purposes, the Hurd is a modern Unix-like kernel.
> > The Hurd uses the GNU C Library, whose development closely tracks
> > standards such as ANSI/ISO, BSD, POSIX, Single Unix, SVID, and X/Open.
>
>This is true.  If you look at the Debian distribution of the Hurd,
>many of the problems getting packages to run on the Hurd are that the
>software assumes or requires Linux.  It is rarer that where the Hurd
>diverges from e.g. POSIX proves a practical problem.
>
>Neal
>
>[1] http://www.gnu.org/software/hurd/hurd-paper.html

Of course if the Hurd were to "succeed" (spread, whatever that means), then
it would be the Mach version of 'capabilities' (Mach "ports") that would
become the common model.  We seldom discuss the Mach model of
ports as "capabilities" on this list.  Why is that?

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