bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A niche for the Hurd - next step: reality check


From: olafBuddenhagen
Subject: Re: A niche for the Hurd - next step: reality check
Date: Thu, 20 Nov 2008 03:42:22 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

Hi,

On Thu, Nov 13, 2008 at 11:17:29PM +0100, Michal Suchanek wrote:

> I am not familiar with the Hurd internals either. However, as I
> understand the current design it uses the UNIX security model with
> users and groups down to the very basic services.

This is partially true: The Hurd primarily implements POSIX, and
consequently the interfaces are geared towards the UNIX security model.
Yet, it's all based on capabilities, which allows a lot of things not
possible in a "real" UNIX.

> The security model used by EROS and Coyotos uses capabilities instead.
[...]
> However, this requires fundamental redesign of the current Hurd.

I'm not convinced of that.

Things are much more complicated in reality; but conceptually, UIDs on
Hurd can be regarded more or less as directory capabilities, giving
access to a set of other, more specific capabilities.

UIDs being capabilities means that a process can have any number of
them; and also pass them on to other processes at any time -- just like
other capabilities. Now if you create special users with limited
permissions -- possibly even having just a single real capability -- you
can use the UIDs the same way you would use generic capabilities: Supply
a process with a set of capabilities (UIDs) giving access to just the
objects it needs for operation.

This is not as elegant and efficient as a pure capability system of
course; but I believe that it can work well enough in practice. The
great advantage is that it interacts nicely with the traditional
UNIX-like environment; and that people being already familiar with the
user concept, should be able to grasp the concept of such pseudo-users
easily.

This is what the Hurd is all about, what I like it for: It opens new
possibilities the users can take advantage of, but without forcing them;
without throwing the familiar UNIX environment overboard entirely.

> This is why some people think that it would be also a good idea to
> drop the now-obsolete Mach and start with a modern kernel which is
> also incidentally designed to support capabilities.

I think there are some misunderstandings here. Your information seems to
originate mostly from the l4-hurd list discussions from the "Coyotos
era"; while you are lacking both the background that lead up to it, and
insight about what happend when these discussions died down...

First of all, you may not be aware that most of the people taking part
in these discussions, like you, have not been involved in Hurd
development before, and know very little about the original Hurd/Mach
design. Neal and Marcus -- the initiators of the original Hurd/L4 port
-- being the notable exception.

The motivation for the Hurd/L4 port were Mach's general slowness, and
the lack of resource accounting. It had very little to do with security
considerations (except for the fact that lack of resource accounting
opens various DOS possibilities of course); it certainly had nothing to
do with Mach not being suitable for a capability system.

Only considerably later, and after implementing some major parts of
Hurd/L4, it started becoming clear that it is not feasible to implement
a system like the Hurd on top of L4, because -- unlike Mach -- it lacks
kernel support for capabilities. Only then they (mostly Marcus) started
digging deeper and deeper into the security stuff, and under Shapiro's
influence got a bit carried away with it...

In spite of initially high hopes, it became more and more apparent
though that the goals behind Shapiro's designs are quite different from
the Hurd's goals after all -- the doubts finally culiminating in the DRM
debates. At this point he pretty much fell silent on these things, and
it probably didn't become quite clear from the list that his doubts
extended not only to the actual design of Coyotos, but the whole high
security direction in general -- he actually admitted that he got
carried away. (Well, I don't remember his exact words... Hope I'm not
misrepresenting his opionions again.)

Afterwards Marcus started work on a new microkernel, with the intention
of doing a considerably less radical redesign than a Coyotos-based
system would have been -- but finally lost interest alltogether; while
Neal seems to be concentrating entirely on the resource management
question again, which already was the major driving force behind his
Hurd/L4 work.

> For me the current Hurd is not of much interest anymore. From my point
> of view the very foundation is fundamentally flawed,

That's a rather bold statement, considering that just a few paragraphs
above you admitted to an ignorance of the existing Hurd design...

-antrik-




reply via email to

[Prev in Thread] Current Thread [Next in Thread]