Re: Niches for the Hurd: evaluation method; was: DRM musings, capabilities and stuff

[Michal Suchanek]

2008/12/22  <olafBuddenhagen@gmx.net>:
> Hi,
>
> On Thu, Dec 18, 2008 at 04:03:39PM +0100, Michal Suchanek wrote:
>> 2008/12/18  <olafBuddenhagen@gmx.net>:
>
>> I find persistence and storage mechanism that works well with it quite
>> useful.
>
> Well, *we* don't find EROS-like persistence useful for our purpose. I
> never found it useful, as you might remember; and Marcus, who was
> advocating it for a while, finally came to the very same conclusion.
> (After stumbling over some site with various articles explaining the
> issues much better than I can.)
>
> I'm not sure about Neal's current stance.

I am sure that I do find it useful.

I see that implementing it correctly might be somewhat challenging,
especially since such feature is uncommon. But given a working
implementation I can use I would certainly like to use it.

>
>> I also do not see why do you want to throw away secure IPC
>
> We don't want to throw away secure IPC.
>
> EROS/Coyotos doesn't have a monopoly on secure IPC, though. Its fully
> synchronous IPC is not suitable for us -- even Shapiro admitted this;
> and while he backed out the changes from Coyotos again (don't know the
> specific reasons), Marcus and Neal still think that a partially
> asynchronous mechanism is more useful for us.
>
>> and resource management
>
> The main idea behind Neal's resource management work is that
> applications should be involved, which is in direct opposition to
> Shapiro's approach.

I would like to see a design of a system where resource management
works at least in theory by involving the applications. It sounds like
a good idea but protecting from malfunction of the involved
applications is somewhat challenging.

>
>> As I said numerous times hiding things from child process can be
>> turned into hiding things from parent process.
>
> No, you didn't -- at least not on-list. All you did so far was
> repeatedly asserting that any security automatically means being able to
> hide anything, without anything to back this assertion.
>
>> After all, your login shell is normally started by some other service
>> which has all the power to hide things from it.
>
> So?
>
>> The only difference we are discussing round and round is whether this
>> service is configured to possibly hide something from all shells or if
>> there is a 'root' shell that can access everything.
>
> No idea what you mean.
>
> All processes started by the user are descendants of the user's session,
> and thus the user has full control over them.
>
> Perhaps you mean that the implementation of the user session itself
> could be treacherous, which is of course true -- but again, this
> requires the admin to actively take part in the treachery. It's not
> something implicitely provided by the standard system mechanisms.

The only security model I have seen proposed for memory protection is
granting memory to child processes.

That means that a parent process decides what memory its child process
can access. In a tidy way this is done by allocating non-overlapping
pieces of memory for the children from the parent's (which the parent
can access but usually does not).

The user session is not the top process in any system I know. It is
started by another system service.

There are several possibilities how that service might create the
'administrator' session.

a) give it all the memory not occupied by the kernel and system
services - easiest, cleanest.

b) as (a) but additionally give a 'root handle' that gives access to
all memory. This would be useful for system debugging but probably not
so useful on a production system.

c) as (a) but also provide a 'drm memory' service  - a system service
that allows giving memory to some process and revoking your access to
that piece of memory at the same time. You would get a revocation
handle instead which you can use to get back the memory but without
the contents.

d) (b) + (c)

Of course, other schemes are possible but I do not know any other that
adds significant features.

The 'drm memory' service is an addon which is possible to add to any
system that implements memory protection. For example, on Linux all
the applications running as the same user can access the memory of
each other and root can access all memory. So on Linux you would need
a suid executable and a modification that does not allow the root user
access to all memory. Given that several extensions for limiting the
root account privileges exist (such as selinux) it should not be too
difficult to add this feature somewhere.

Normally you can choose how effective the 'drm protection' is - in (d)
you can defeat it by using the root handle. However, security
involving hardware encryption and verification of system integrity by
means of hardware cryptography device can enforce the 'drm
protection'. Some applications might refuse to run on system that is
not known to implement effective protection.

>
>> > Everything that was said about a POSIX layer for Coyotos (or a
>> > Coyotos-like ngHurd) implies a distinct POSIX environment, which
>> > allows running existing applications in some kind of jail, pretty
>> > much isolated from the "native" environment with new applications.
>> > This is not acceptable IMHO. The Hurd allows running traditional and
>> > new applications *in the same environment*. This is what makes it
>> > attractive to me.
>>
>> Since all applications would be run each in its own jail by default I
>> do not see anything wrong with that.
>
> Everything is wrong with that.
>
> I do not want a system which has one part that is essentially UNIX for
> "legacy" software, and another part that is something completely
> different for the Brave New World. What I want is a system with only one
> integral part -- being mostly UNIX-compatible and UNIX-like be default,
> and yet offering many new possibilities; more generally, giving the user
> much more control over the environment.
>
> This is what the Hurd provides.

Thus I find the Hurd unsatisfactory. It provides only the ancient
broken interface with many inconsistent APIs to both legacy and native
applications, and only allows introducing new features by manipulating
something 'behind the scenes', outside of the advertised POSIX
personality.

I would like a system that allows new (or ported) applications to use
a simple consistent interface that allows access to all features of
the system. Since the new applications should run isolated there
should not be much difference between running a native applications
and a POSIX application inside an isolated POSIX environment once you
find out what support configuration and tools POSIX applications
typically expect.

Thanks

Michal