bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Michal Suchanek
Subject: Re: A niche for the Hurd - next step: reality check
Date: Thu, 13 Nov 2008 23:17:29 +0100

2008/11/13 Arne Babenhauserheide <arne_bab@web.de>:
> Am Donnerstag 13 November 2008 21:13:52 schrieb Michal Suchanek:

>> 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.
>
> I would provide it basic internet connectivity and have it request my password
> for temporarily getting additional permissions (just adding the correct
> group).
>
> $ addauth -p firefoxPID -g filewrite
>
> is a crude example for allowing file writing, which would be removed after the
> filewriting operation.
>
> (I don't know if I currently need sudo for that)
>
> Or a bit more finegrained: firefox would spawn a process for file transfer and
> request filewriting permissions for it.
>
>> 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.
>
> For most things I view in viewers (images, movies, music) this wouldn't be
> much of a problem (ignoring metadata for the time being).
>
> Text editors wouldn't be a problem either.
>
> OpenOffice would be a problem, though. But it still could do the filewriting
> by momentarily requesting additional permissions (I don't write files all the
> time) and save all its temporary saves in its config dir with only its own
> permissions.
>
>> 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.
>
> There's quite a difference between getting code from some central place (i.e.
> Debian) or getting it via email.
>
> Many people just open programs they get via mail ("hey, look, I found a great
> game!").
>
> With the Hurd I could then just say "OK, open with game permissions".
>
> And then it won't be able to access the network or modify files (aside from
> the ones it creates itself in dirs games may affect).
>
>> 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.
>
> But these are bugs - they will eventually be fixed.
>
>> Yes, the critical bugs aren't that common. But good security should
>> protect you from most of them, and it can be done.
>
> Ignoring bugs in the security system - yes.
>
> (there's almost always a catch - but at least this would provide two layers of
> security and would make it considerably harder to exploit a weakness in a
> single library, since weaknesses in the security system would naturally also
> be fixed quite quickly)
>
>> 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.
>
> Since I don't know enough about the Hurds internals I need to ask: How much
> work would it be to adapt a shell (and the subhurd code) to do just this?

I am not familiar with the Hurd internals either. However, as I
understand the current design it uses the UNIX security model with
users and groups down to the very basic services. This security model
has poor granularity which makes it flawed by design.

The security model used by EROS and Coyotos uses capabilities instead.

That is, the shell is a capability manager that has a collection of
all the capabilities the user possesses - it is the single process
with full user rights.

When it executes a new process it gives it a piece of memory and cpu
time, and possibly a graphical window if such thing is available.
Whenever the process wants to access a file for reading or writing it
calls the shell, and the shell shows a file browser (or just pauses
the process and shows some flag somewhere) which allows the user to
select a file and give the process the capability to access that file
(for reading, writing, or whatever).

In a terminal shell you typically specify a filename as part of the
commandline so the shell could be adapted to give out capabilities
like this.

However, this requires fundamental redesign of the current Hurd. This
is why some people think that it would be also a good idea to drop the
now-obsolete Mach and start with a modern kernel which is also
incidentally designed to support capabilities.

>
> And would you join in?

For me the current Hurd is not of much interest anymore. From my point
of view the very foundation is fundamentally flawed, and I am not a
microkernel or hardware developer so I cannot start a new one.
Still given the Hurd development timeframes it is not completely
impossible I would become one before the Hurd is finished.

Thanks

Michal




reply via email to

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