[Top][All Lists]

[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: Tue, 18 Nov 2008 03:40:34 +0100
User-agent: Mutt/1.5.18 (2008-05-17)


On Thu, Nov 13, 2008 at 10:11:32AM +0100, Michal Suchanek wrote:
> 2008/10/29  <olafBuddenhagen@gmx.net>:

> > Perhaps the biggest difference is that on Linux, even with FUSE,
> > users are limited to a fixed set of trusted filesystems provided by
> > root. On the Hurd, a user can mount *any* filesystem, no matter
> > where he got the translator from.
> Not really.
> I did not need to be root to test my FUSE filesystem

Indeed, it turns out that arbitrary FUSE modules can be mounted, once
the user is part of the "fuse" group -- so the barrier isn't very high
in practice. Some clueless person had told me that it wasn't possible...

However, while reading up of FUSE, I found another advantage of Hurd
translators: There is no need to prevent suid binaries or device files.
The Hurd security concept makes sure that a filesystem can never give
the client any privileges the mounting user doesn't have.

> > This of course also fits under lightweight virtualization.
> Virtualization is the current hype because it is used instead of
> security and reliability in the system.

It is one of the reasons, yes.

> There are quite a few solutions with various degrees of weight, and
> some aren't extremely heavy. However, they are mostly restricted to
> full emulation (slow) or specific hardware features (x86).

Have you read the blog entry I linked somewhere earlier in this thread?


I touched on all these aspects in there...

> >> If most systems just differ by the translators setup on them,
> >> people could even transfer their whole environment from one
> >> computer to another one without needing root access or more root
> >> interaction than creating a new user account. "I want my tools" ->
> >> "no problem, just setup your translators".

> How is this easier than carrying around an eeepc/olpc?

The obvious advantage is that you don't need any big and complicated
hardware -- just a dumb data carrier, or even just a network connection.

Also, using your own hardware is not always possible and/or allowed.

Last but not least, if you have other systems as well, keeping the
environments in sync is much harder than if you just use the *same*
environment everywhere.

> I understand a flash drive could be lighter but you can just boot from
> the flash drive on bare hardware or in full virtualization - i do not
> see what the Hurd can bring here.

Also not always possible/allowed, and less efficient and convenient.

> Since networking or drive access is possible you can still access
> resources available from the system.

Possible, but often awkward.

Of course the alternatives you are proposing (carrying own hardware, or
carrying a medium with a whole system image) each have their own unique
advantages as well.

Really, you are comparing apples to chocolate bars here.

> And if you run sparc and you come to a ppc you are out of luck anyway

We explicitely discussed the fact that you might need to compile your
own translators on the host system, unless using translators written in
interpreted or JIT-compiled languages.

I *never* suggested carrying around compiled binaries -- this just
doesn't make sense in a free software environment.

> > So for a while some Hurd developers were contemplating a system
> > based partially on Coyotos, and quite similar to Coyotos in fact.
> > However, while such a highly secure system might be a good niche, it
> > would have little to do with the Hurd really. After a while they
> > realized that this is not quite the right direction, and gave up on
> > the idea.
> If I understand it correctly the problem here is not the high security
> but the fact that the security model of the Coyotos system allows
> effective DRM (Digital Rights Management).

It's not that Coyotos incidentally allows effective DRM. The problem is
that Coyotos is fundamentally *designed* to support this kind of use

The whole phisosophy behind Coyotos is in direct conflict with GNU
philosophy, and consequently the design is fundamentally incompatible
with our goals. This is the conclusion Marcus finally arrived at, and
IIRC tried to express in his latest posts in the hurd-l4 Coyotos

> There is no viable alternative, though.
> The L4sec which also focuses on exploring security options is probably
> not going to be finished anytime soon.

FWIW, there is also seL4, which is more or less production-ready AIUI...

But that's beside the point really. The true alternative is writing our
own microkernel, implementing just what we really need.

If there is one thing to be learned from the troubles with Mach, then
L4, then L4ng/L4.sec, and finally Coyotos, it is this: Trying to build
our own system on top of some existing microkernel just doesn't work.

> > All the time I was convinced that if not going to such extremes as
> > Coyotos -- implementing POLA throughout the system -- but instead
> > only trying to confine some of the most dangerous applications, this
> > could be implemented quite well on the existing Hurd.
> The problem is that any application is equally dangerous. When your
> PNG library has a buffer overflow a virus can be carried by otherwise
> normal looking picture. Now if you consider your browser dangerous and
> enclose into a subhurd you can still download the image, and view it
> with a viewer that is not enclosed and also links to the broken
> library.

Considering how incredibly many security exploits have been found in all
kinds of multimedia decoders over the past years, you can bet that I'd
consider image viewers and video players (and pdf readers too) among the
most dangerous applications.

I see little reason to confine ls or rm, on the other hand.

Security is never all-or-nothing. There is a lot of middle ground
between traditional UNIX and Coyotos, and some of this middle ground is
what I am interested in.


reply via email to

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