2008/11/13 Arne Babenhauserheide <[EMAIL PROTECTED]>: > 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
