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

[Arne Babenhauserheide]

Am Sonntag 23 November 2008 16:20:01 schrieb Michal Suchanek:
> > Would you want your coding to benefit a locked down society in the long
> > run - especially when you code on something as user-enabling as the Hurd?
>
> Well, you don't stop using knives because people can be threatened and
> killed with them, do you?

To stay inside the metaphor: 

I don't help spreading knifes with remote cutting control to people who just 
need to cut their bread. 

We already have knives, and they are tuned for the thing they are being used 
for: cutting things. 

A system designed for allowing DRM is like a knife designed to allow for 
remote control of the stuff which can be cut with it. 

"Sorry, you are only allowed to cut Sony bread with Sony-licensed knives". 

Sounds quite evil, doesn't it? 

> Perhaps there is an alternative, and perhaps it turns out that having
> security implies allowing DRM.
>
> Designing a secure system that does not support DRM would is the only
> proof that such thing is possible.

"Can be used with DRM" and "designed to allow DRM" are two very distinct 
ideas. 

What level of security do you need? 

The one which is still security for the user of the one which is security 
against the user? 

> However if it is not I still do not want to break computer systems
> because DRM is unwanted. That would be way too similar to DRM people
> breaking systems because they want to control the information world.

You don't break computer systems by not supporting DRM. 

You just decide against certain models. 

Also all security has a cost inherent to it. So, cutting out all the soft 
things like development time and stuff, not supporting DRM will have higher 
performance in the end. 

> > And it might be that my understanding of capabilities just is flawed, but
> > in the long run I don't see where
> >
> > $ addauth write_coresystem
> >
> > really differs from a pure capabilities system in actual use.

I need to cut the next part into several fragments for being able to answer: 

> First, the users of a pure capability system are aware that the

BREAK!

This needs to read "the current users of pure capability systems are aware". 

Regular computer users aren't even aware that there is such a thing as user-
rights which goes above "OK, I can do this, but that eeds my admin-password". 

In real use the system will have to ask "do you allow access to teh CD-Drive" 
to be usable for regular users. 

And there the difference vanishes. 

> security model is different and are forced to think about security
> differently. 

...forced...

No regular desktop user will use that. They will just stay with Windows. 

> This makes it more likely that they will use the full
> potential of the system 

Who does really use the "full potential" of GNU/Linux at the moment? 

I doubt it's more than a very tiny percentage. 

This will not differ for a capabilities system, but I am quite sure that 
people will stumble over a pure capabilities syntax more often. 

> and at the same time they will not indroduce
> security problems by thinking about the system in the wrong terms.

To be able to have a go at this: Please give a line with which you define 
capabilities in a pure capabilities system. 

> I do not think so. A typical application only needs to read or write a
> single file which the user can specify directly so there is no need
> for many capability classes. 

What about my mail program here? 

* Reads and writes many files, 
* accesses the network, 
* can show different file types, 
* can open files from anywhere on my disk (for attaching) and 
* can save files to anywhere on my disk (save attachments to the place where I 
want to store them). 

This, together with my webbrowser, is the program I use the most. 

To support capabilities, you'd have to either give it full access to anything 
I have access to, or do a deep rewrite to allow it to ask for access to 
anything. 

In the first case you just defeated your security, in the second case there is 
quite much work ahead of you to create a system I'd deem usable. 

> One should be more cautious about applications that can access the
> network but since the default is to not allow any application access
> anything there is no special profile required for that, perhaps only a
> warning that the application is capable of transferring the file over
> the network.

Would that mean, that I couldn't use my webbrowser directly when starting it? 

What about my BitTorrent program? 

> As the multiple-mail followup suggests adding sound security into UID
> based system is very difficult at best, and hard to get right.

"You discussed for a long time, so your result must be weak". 

That reasoning is very questionable. 

> > You can do permissions much more practical, for example not allowing any
> > writes except for specific programs.
>
> Note that the ability to read files is also a security risk. By
> compromising a single application the attacker might gain access to
> all your data or learn about more security flaws by reading everything
> you can access.

But since I am a normal user, I only have access to my own files. 

No way he can access shadow or similar with just my permissions. 

> "your next action" should be any open(). 

What about multi-file access with dependencies?

If A contains "b" then read B, if not read C. 

Next action is a logical question, not a technical one. 

> However, you cannot tell when
> that open() happens unless you intercept any open() in libc 

Or you setup a translator on the filesystem the program can access. The 
translator can then interrupt the open(). 

> likely look for files to work on so it should not be too hard to
> automatically set up environments for POSIX applications on a
> capability system.

How much effort would it be to port my KDE? 

> I cannot even think of "for 1 minute" to be considered useful for anything.

How about "capture my network traffic for one minute"? 

This one might be trivial, but it is an example. 

> > $ settrans -a target_file allow_write PID
>
> Assuming the PID is not reused (unlikely given the limited number of
> PIDs but you could perhaps look up a unique task ID given the PID and
> ignoring race conditions with the application terminating) where would
> you attach that translator?

As the line shows I'd attach it to the file - Hurd style. 

About the number of PIDs: The translator could just check the current 
application identification (for example name and start tiem) on that PID and 
automatically shut down when that changes. Since the filesystem is already 
damn slow compared to CPU time, this accesses shouldn't hurt. 

> if you do that globally is it possible to stack these so that multiple
> applications are allowed?

Sure, using filters, so it ignores the access translators below it (see 
Sergius work). 

> > Via GNU/Linux many people already know the GNU tools (and those who don't
> > aren't in a possible target group), so a new system should better use
> > these tools, so people don't have to learn new stuff again.
>
> The Hurd as it is has been tied to a tiny group of users with very
> arcane lore for a very long time already. It is because it offers only
> very insigninficant advantages and is very hard and impractical to
> use.

Aside from not being connected to the earlier line with more than unsure 
thread, your conclusion misses the glaring obvious point: 

Linux has hundreds of kernel developers. The Hurd has about 5. 

Do I really have to say more? 

And besides: I don't know much arcane lore. What I know which goes beyond 
GNU/Linux is mostly "qemu hurd.img", "settrans" and "addauth", and the second 
one only for a few weeks now (plus some of the theoretical background behind 
it, but I don't need that for using the Hurd, I just learned it, because it 
interests me). 

But at least you now showed your color and viewpoint. 

Did you already try using the Hurd, for example in qemu? 

Info: 
- http://www.gnu.org/software/hurd/hurd/running/qemu.html

Direct download: 
- http://ftp.debian-ports.org/debian-cd/K16/debian-hurd-k16-qemu.img.tar.gz

Best wishes, 
Arne
-- 
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt

signature.asc
Description: This is a digitally signed message part.