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

[Michal Suchanek]

2008/11/21 Arne Babenhauserheide <arne_bab@web.de>:
> Am Donnerstag 20 November 2008 23:24:42 schrieb Michal Suchanek:
>> As I see it the problem with Coyotos is more political than technical.
>> Technically it might be possible to just not use additional feature
>> present in the kernel but politically it is a problem if a DRM-capable
>> design is popularized by being used in the Hurd.
>
> Here "political" means thinking further than only the scope of your current
> project, so this is in my view a very good thing.
>
> 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?

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.

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.

>
>> I personally want as few and as simple concepts as possible to make up
>> the foundation of the system and the current Hurd does not provide
>> that for me. The direct integration of user tools with the capability
>> concept which would supposedly be part of Coyotos would greatly
>> simplify the system compared to the Hurd.
>
> This would mean having to rewrite all user tools to using capabilities, while
> the Hurd can works with the existing tools.
>
> Remember please, that the Hurd doesn't have a 100 people experimentor team,
> and that the same set of tools will be used on other platforms which have the
> user concept.
>
> 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.

First, the users of a pure capability system are aware that the
security model is different and are forced to think about security
differently. This makes it more likely that they will use the full
potential of the system and at the same time they will not indroduce
security problems by thinking about the system in the wrong terms.

>
> In real life situations you will have capability classes (since developers
> don't want to reinvent the wheel all the time), and these can be expressed as
> UIDs and GIDs.

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. Perhaps for some multi-file viewers it
might be desirable to specify a directory instead of a single file but
that still does not require anything overly special.

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.

As the multiple-mail followup suggests adding sound security into UID
based system is very difficult at best, and hard to get right.
        
Arne Babenhauserheide   
> Am Donnerstag 20 November 2008 23:36:40 schrieb Michal Suchanek:
> > Still you should get as much security as practical because you never
> > know in advance what is a threat, and it's the default barriers on
> > which you rely for mitigating yet unidentified threats. The UNIX
> > concept simply does not make security practical. Or at least I have
> > not seen an extension to it that does.
>
> How about the subdo idea?
>
> Just open all applications with a reduced permission set and add the option of
> giving additional permissions.
>
> 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.

>
> Or just oneshot permissions: "OK, now you'll be in group X for 1 minute / your
> next action"
>
> (though "your next action" is hard to measure)

"your next action" should be any open(). However, you cannot tell when
that open() happens unless you intercept any open() in libc (and then
you do not have to give the permission by adding the application to a
group but instead have libc call a program that asks you about giving
permission or rejects the permission based on policy) or port the
application to use some get_capability instead. Also note that a
typical POSIX application only needs the configuration files that came
with it, some temporary space in /tmp and a $HOME where it would most
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.

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

Arne Babenhauserheide   
>Am Freitag 21 November 2008 05:17:33 schrieb Arne Babenhauserheide:
> You can do permissions much more practical, for example not allowing any
> writes except for specific programs.
>
> Or just oneshot permissions: "OK, now you'll be in group X for 1 minute /
> your next action"
>
>Or simply just allowing writes when a translator gets set up onto a file
>beforehand which checks the accessors identity.
>
>something like
>
>$ settrans target_file allow_write PID
        
Arne Babenhauserheide                   
> Am Freitag 21 November 2008 06:46:11 schrieb Arne Babenhauserheide:
> > $ settrans target_file allow_write PID

> For a temporary allowance, this should maybe be

> $ 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?

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

Or would you somehow enter the subhurd in which the application runs
and attach it there?

> So when the translator shuts down it is gone (active translator).


>
> And the Hurd offers the additional advantage of being compatible with most
> existing user tools, so these capabilities can really be used in a general
> purpose desktop (instead of being tied to a user group with arcane lore for a
> very long time).
>
> 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.

Thanks

Michal