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

[Michal Suchanek]

Hello,

Sorry about the late reply.

On 23/01/2009, olafBuddenhagen@gmx.net <olafBuddenhagen@gmx.net> wrote:
> Hi,
>
>  On Tue, Jan 13, 2009 at 01:44:59PM +0100, Michal Suchanek wrote:
>  > 2009/1/13  <olafBuddenhagen@gmx.net>:
>
> > > On Fri, Jan 09, 2009 at 06:22:27PM +0100, Michal Suchanek wrote:
>
>
> > > I'm not saying it is impossible to do for a really dedicated person.
>  > > But surely you don't want to claim that this is equivalent in
>  > > practice to a system where the user running an application has full
>  > > control over it in the first place?
>  >
>  > And again the full control is most likely a matter of configuration,
>  > not the system in question.
>  >
>  > You might not allow any application to use memory you cannot access.
>
>
> And again, you are wrong. Design and feasible use cases are *not*
>  orthogonal in practice.

They are certainly not. I never said they are.

>
>  Of course you could hack Coyotos to deny processes from hiding stuff
>  from their parents. Only that would be a damned stupid thing to do, as
>  it would completely compromise the security system of Coyotos, which
>  heavily relies on this property.

I do not see where it does. It relies on system services being able to
hide memory from their clients. As the system services are typically
started by another service or the administrator the security would not
suffer much if the service would not be able to hide from the
administrator.

It might however hinder "suspicious cooperation" where one user
provides the code for a service and another data to be processed by
the service, and they want to be able to run the service in such a way
that they neither can see the part the other put into the process.

>
>  You can't just change a fundamental property and still have a functional
>  system. All services need to be designed in a completely different
>  manner, to work in the hierarchical security model we are proposing.

Note that the genode system that you mentioned does use the
hierarchical security model and still uses DRM memory for services. It
does not even guarantee you get the memory back once you donate it to
a service to process your request.

>  > If you do not know any functionality that is actually forsaken here
>  > either then there might be no reason to stick to dbus at all.
>
>
> Who says I don't? And how is it relevant whether *I* know of specific
>  dbus use cases?
>
>  I feel neither entitled nor inclined to discuss the merits of dbus. It
>  is totally beside the point. Merited or not, GNOME and OpenMoko and
>  others are using it extensively for interaction between components, and
>  thus integrating anything properly in these environments requires using
>  dbus. How hard is it to understand that?

And what of that?

If you think you cannot live without gnome and its supposed
integration you just port dbus and make use of the system features
available to make it as secure as possible.

If you cannot live without gnome but don't think the supposed
integration is crucial just ./configure --without-dbus.

If you can live without gnome just throw it away completely.

I don't see any problem in either approach. The dbus communication
transport is supposedly well abstracted so much it should be possible
to use it over network, more so among processes in isolated POSIX-like
enviroments on the same machine.

>
>
>  > >> If you went on the "i do not need this but I imagine that somebody,
>  > >> somewhere might at some time ..." then you would include every
>  > >> function possible in every piece of software, and every piece of
>  > >> software would be an operating system on its own right with
>  > >> everything including the kitchen sink already packed in.
>  > >
>  > > The point is precisely *not* to implement all possible system
>  > > functionality in each single application, but rather to integrate
>  > > applications with each other, so existing functionality can be
>  > > reused in all kinds of situations.
>  >
>  > But we are talking about adding (porting versus not porting) dbus
>  > here, not about application integration.
>
>
> I don't know what *you* are talking about. *I* am talking about the fact
>  that interacting with existing components requires using existing
>  interfaces.
>
>  I merely pointed out -- as you brought this up -- that integrating
>  existing components is not bloat, but a remedy against it.

It depends on the value the component brings. This might be highly
subjective and depend on the way you intend to use the system, of
course.

>
>
>  > > So you agree that it's possible to improve things, without forsaking
>  > > existing interfaces :-)
>  >
>  > However, our position fundamentally differs in that you want a system
>  > built around legacy interfaces but I want a system with simple and
>  > clean interface that is powerful enough to express the deprecated
>  > legacy interfaces as compatibility layers when applications need them
>  > or abandoning them if they are no longer necessary.
>
>
> Indeed, the difference is that we consider good support for existing
>  software and existing approaches a must, and anything beyond that a
>  bonus -- not the other way around.
>

When you are trying to bring some innovation you cannot do that by
clinging unquestioningly to any established approach, framework, and
piece of software.

Thanks

Michal