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

[Michal Suchanek]

2008/11/20 <olafBuddenhagen@gmx.net>
>
> 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.

Yes, the Hurd is based on Mach which implements ports - capabilities
but hides this under the POSIX interface.

In my view saying "this is like posix but it's really capabilities,
and you can do this, that and even more now" is much harder for the
users than saying "our system is based on capabilities, and these work
like this".

Note that even POSIX has the UNIX permissions, ACLs, and Windows which
are somewhat POSIX-like have ordered ACLs. Still most users will only
want a GUI dialog which allows them to share a file with another user
and are not interested in the internals of the system. These are
important for the software developers and administrators, not users.

The "it's like posix but really capabilities" approach seems to me
like translating software into a different language. It seems like a
good idea in the start but each translator invents new terms for the
words translated because no well defined translation exists in the
target language, and since the application is translated it's no
longer understandable for people who know the original language. Only
people who know both languages can guess from what words in the
original language the translation was made and thus understand the
application with additional difficulty.

If you implement something like POSIX and then allow adjusting the
POSIX layer behind the scenes it is more confusing than just saying
it's not POSIX anymore.

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

I think most of the people talking in the discussion were Hurd
developers. There were very few people in fact and I think I was an
exception not being a Hurd hacker.

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

If I recall correctly Marcus tried to come up with secure design that
does not require DRM and beleived it was possible.
As I see it the problem with Coyotos is more political than technical.
Technically it might be possible to just not use additional feature
present in the kernel but politically it is a problem if a DRM-capable
design is popularized by being used in the Hurd.

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

My limited understanding of the Hurd is that there is Mach with its
ports, and on top of that are very few core services and libraries
that hide this interface and use it to implement a POSIX emulation
with some extensions.

I have used the top part and the bottom part seems conceptually easy
enough but admittedly I have not looked much into the middleware that
translates between the two.

Still for me the fact that the user tools work in terms of UIDs is
flawed even if there are expanded possibilities how UIDs can be used.

I personally want as few and as simple concepts as possible to make up
the foundation of the system and the current Hurd does not provide
that for me. The direct integration of user tools with the capability
concept which would supposedly be part of Coyotos would greatly
simplify the system compared to the Hurd.

Thanks

Michal