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

[Michal Suchanek]

2008/11/13 Arne Babenhauserheide <arne_bab@web.de>:
> Am Donnerstag 13 November 2008 10:11:32 schrieb Michal Suchanek:
>> How is this easier than carrying around an eeepc/olpc?
>
> I can use the processing power of the system at hand instead of having to rely
> on my laptops speed.
>
> This means: I won't have to carry a whole system. When there's a Hurd on a
> Computer I can turn it into a system where I feel at home with far less
> effort.
>
>> 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.
>
> It brings access to all the systems resources, including stuff which isn't
> supported on a normal OS you might have on your USB-stick.
>
>> And if you run sparc and you come to a ppc you are out of luck anyway
>
> Not with translators written in Lisp (or some other interpreted/JIT compiled
> language).
>
> With them you can just start your translators on any hardware.

This would require rewriting most of the Hurd in Lisp to allow
carrying around modifications to even more basic services.

Still that would make the Hurd technically interesting in itself, even
without the mobility bonus. The mobility would not be that great after
all since Hurd systems are quite rare. But at least you could carry
some customized environments between systems that you set up to accept
them which is still a problem for state of the art systems today.


>
>> The problem is that any application is equally dangerous.
>
> I'd rather say "any application you normally open is equally dangerous".
>
> But with restricted environments it would be possible to autostart
> applications without endangering the system.
>
> Just look at what people do with Java Webstart. Java can confine applications.
> With the Hurd any kind of applications could be confined in a similar way.

As far as I understand the Java security model there are two kinds of
Java applications: trusted and untrusted.

Trusted applications can do anything the user can, untrusted
applications should be able to

- get system resources (RAM, cpu time) up to the limit specified for
the JVM process
- get access to part of the screen and user input - typically quite
dangerous in today's graphical environments
- connect over the network to the server they were downloaded from.
Not sure if they can connect to a different port

This adds a "guest" security level to the two-level "root"+"user"
security model.

The security is implemented as a bolt-on in the Java interpreter by
enumerating privileged classes and methods in some specification and
making checks in the Java runtime that the untrusted application does
not abuse them.

An application on the Hurd could be possibly enclosed more efficiently
by replacing handles to general translators with handles to restricted
translators. There could be even multiple profiles like:

viewer - can read files
browser - can connect to the network
downloader - can connect to the network and write files

Still what profile would you assign to Firefox? It does all of the
above so it can read all your files, make enough copies of them to
fill your disk, and send them all over the network.

And when you start actually doing something you need an editor - a
program that can write files. And since it often shares many of the
bugs of the viewers through use of libraries confining the viewers was
not that great success.

>
>> 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.
>
> This is for normally safe programs which get a bug.
>
> As an example of the difference: Would you open a Python script I sent you
> without first looking at the code?

I do that daily. My ALSA setup scripts are written in Python. I never
looked at them since Python code makes me want to wander off to the
right. They are technically signed by Debian but I am not sure how
much of an assurance that is given the volume of code Debian signs
daily.

And viewing a picture might be as dangerous - there are always bugs in
some libraries but most people aren't paranoid enough to suspect data.
Yes, the critical bugs aren't that common. But good security should
protect you from most of them, and it can be done.

>
> With the Hurd you could just execute it in a subhurd in superunprivileged mode
> and see what it does without having to fear for your system.

On a secure system I would not have to specifically set up a special
environment for that.
The shell would simply assign limited permissions to any process at
startup, and should it want more it would have to ask me through the
shell.

Of course, some processes would be privileged - for example, a browser
(or better yet a part of a browser)  would be set up with rights to
access the internet.

Thanks

Michal