GNU Hurd

[Neal H Walfield]

> Looking at the HURD programming progress shows up that there was
> some progress in 1996 and 1997. Please note that this was some years
> _after_ Linux became successful. For this reason, I cannot see that
> Linux should be responsible for the HURD desaster.

Looking from whose perspective?

The Hurd has been making significant progress in the few last years.
Just take a look at Debian.  Of the 7000 packages or so which are
available in the unstable distribution, half of them are currently
compiled for the Hurd.  This includes important software such as gcc,
XFree86 and LaTeX.  A lot of the remaining packages have small errors
or "Linuxisms:" no fault of the Hurd itself; developers just sometimes
forget that Linux != POSIX.  These can usually be fixed with a ten
line patch, however, it is a matter of systematically going through
the packages and producing these diffs, submitting them and following
up on their merits of the those of just being portable.

The last major stepping stone to POSIX compliance is threading.  With
pthreads, at least another third of the Debian archive should be
compilable.  This work is currently underway -- in fact, it is being
undertaken, in part, by one of the people that this flame is directed
at.  Although I cannot say when it will be finished, from my
perspective, it is making steady progress.


But what about the fact that the Hurd has taken so many years to
gather momentum and become usable?  Here are the facts: Linux is, for
the most part, a _reimplementation_ of Unix.  The interface is
essentially the same; innovation has been in the implementation.  The
Hurd, on the hand, is a _redesign_.  Thomas, Roland et al sat down not
to clone Unix, but, as in traditional GNU style, to take a look at
what is available, find its faults and design a new system that is
more flexible and more powerful.

In my experience, designing is never as easy as implementing.  When
you design, you need to think about the interaction between all of the
components: you need vision.  You must experiment with ideas, try them
out and then throw them away and start of scratch.

But does Unix need a redesign?  At least according to those who
designed the Hurd, it does.  But, if you do not need user flexibility
and do not mind administration head aches, then, Unix is fine.  And if
you do not need security, Unix is fine.

On a standard Unix system, a normal user has no power.  He can, of
course, run his applications, gcc, bash, LaTeX, etc.  But, he can do
nothing _within_ the system.  He cannot play with the vfs even if he
can access the backing store; he cannot create subsystems nor chroots;
he cannot run most daemons.  Why is this?  The Unix design philosophy
has always been to put as much functionality into the kernel as
possible.  One of the main trade-offs is that changing these features
becomes a privileged operation: if there is a bug in the kernel or it
is given bad data, the user could cause a kernel panic, or worse,
takeover the system.

Take a look at Bugtraq: on at least a weekly basis, there is a new
dangerous Unix exploit available.  One of my personal favorites are
those for wu-ftpd.  Although the programs are clearly to blame,
perhaps, we should shift some of the guilt onto the kernel for not
helping out.

The top targets of crackers are daemons running with root privileges
and suid applications.  But why are these programs running as root?
In Unix, the user and group ids are an inherent part of the process
and privileges may only be dropped -- never gained.  The
authentication scheme is just not flexible enough.

In the Hurd, this threat is brought to its knees.  User and group ids
are orthogonal to processes.  You might consider them similar to id
tokens.  A trusted system server issues id tokens when e.g. given a
user name and the corresponding password.  In this scheme, a process
may have one user id, many user ids, or even, no user ids.  The first
case is similar to traditional Unix.  However, the others are more
interesting.  Having multiple user ids, allows each to be more
specialized.  For instance, I have a driver's license, a library card
and my school id.  If I am speeding and pulled over, neither my
library card nor my school id will not help me.  Only my driver's
license.  The final case permits processes to run with nearly no
privileges on the system.

This model means that a daemon, rather then running as root and then
dropping privileges, may run with no privileges.  Then, when a user
responds to the user name and password prompts, it may contact the
authentication server and ask for a new authentication token.  In
Unix, attackers try to break the system during the authentication
phase where they are almost guaranteed to get root access.  In our
model, if the daemon is compromised, the attacker gets no access: at
least not anymore than he had from the outside.

Attack neutralized!

> If you believe that Hurd is a good idea, then stop talking about hurd
> and start working on hurd. Once it becomes usable and has the features
> requested by the users it will be used by a noticable number of
> people.

We are going as fast as possible.  And you could help, if only by
helping to minimize the FUD.