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

[Michal Suchanek]

Hello

It looks like this other thread has some of the bits I wrote about in
greater detail .. and it also has some other interesting bits.

2008/10/29  <olafBuddenhagen@gmx.net>:

>
> A more serious difference is the ability to mount image files directly
> -- on Linux, you need loop devices for that, which is not very elegant,
> and more importantly can only be done by root.

This is probably because the number of loop devices possible is a
compile-time constant which defaults to 8.


>
> 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. The fuse filesystem implementation only provides a few
functions that are required by kernel vfs for a functional filesystem,
and the kernel passes the results unmodified, at most caches them.
There is probably some restriction on FUSE filesystems like the
inability to present suid executables or device nodes. Your
application can, of course, get insane data, an unexpected error or
wait forever for the request to complete. Your responsibility. You can
always detach the filesystem if you can write certain file (ususally
root only) or kill it.

I did not need to be root to test my FUSE filesystem (although I
mostly use it to mount / from web which is done as root).

Generally it's a compatibility layer that passes requests of
applications that insist on talking to the kernel to an userland
server. Sounds familiar?

>
>> subhurds
>
> Subhurds are nice, but in the current implementation do not really give
> power to users, as they can be started only by root...
>
> I'm not sure how much work it requires to fix this, but I guess it could
> be done in a few months; perhaps weeks.
>
> In any case, subhurds also fit into the lightweight virtualization
> category...
>
>> Simpler virtual computing environments - no need to setup XEN,
>> everyone can just open up his/her computer for someone else by
>> creating a new user account, and the other one can login and easily
>> adapt the system for his/her own needs.
>
> We get the same problem here as above: It is possible in principle, but
> we do not really have the tools to create such custom environments, nor
> documentation and examples.
>
> 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.
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).

>
>> 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".
>
> This is an interesting option -- I actually thought in a similar
> direction already.

>
> A precondition is that the same translators are available. This could be
> incovenient, but shouldn't be a serious problem, as the user can always
> compile them himself.
>
> We also need to be relatively independent of the host system to make
> sure we really get the environment we want. This requires attaching at a
> rather low level... Certainly possible, but again we need tools and
> documentation.

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

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.
Since networking or drive access is possible you can still access
resources available from the system.

And if you run sparc and you come to a ppc you are out of luck anyway
so the ultimate solution is to invest into making hardware lightweight
when it comes to carrying your environment around with you.

> There are actually two other possible niches I meant to mention, but
> somehow seem to have forgotten:
>
> - Safely running dangerous applications
>
> After the demise of Hurd/L4, some of the developers became interested in
> high security systems, and specifically Coyotos. Coyotos is a system
> that consequently implements the Principle Of Least Authority, by
> splitting up the system and all applications in very small components,
> and confining them as well as possible. Much oversimplified it means
> that the web browser for example only gets access to certain network
> ports and certain screen windows, but no access to the user's files,
> except on explicit request. Also the browser consists of many individual
> components with even less authority: The network loader has access only
> to the network, the layout engine has access to no external resources at
> all, and only the user interface can ever access files. This way, even
> if one of the componets gets compromised, it can't do much damage, as
> the component having network access doesn't have access to the user's
> files, and the component having access to the user's files doesn't have
> network access.
>
> 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 is likely possible to
rip this feature out of the kernel but it requires some thinking how
do that right, and complete redesign of pretty much anything above the
kernel. And the outlook that after that the feature can still be added
back is not nice either.

There is no viable alternative, though.

The L4sec which also focuses on exploring security options is probably
not going to be finished anytime soon.

The second problem is that Coyotos is still incomplete so there is no
base to build on.

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

The same for pretty much any kind of file - html, pdf, office documents ..

Since pretty much any file comes from the web there are also very few
"safe" files worth looking at.

Thanks

Michal