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

[olafBuddenhagen]

Hi,

On Wed, Dec 31, 2008 at 02:35:46PM +0100, Michal Suchanek wrote:
> On 31/12/2008, olafBuddenhagen@gmx.net <olafBuddenhagen@gmx.net>
> wrote:
> >  On Tue, Dec 30, 2008 at 12:10:39PM +0100, Michal Suchanek wrote:

> If you want a POSIX system Coyotos is completely out of question.
> 
> I would think that the kernel itself does not provide the constructor
> primitive - I would make it a service on top of a simple kernel.

Indeed the constructor is not part of the kernel itself AFAIK. But at
the microkernel level, all mechanisms and design decisions are
intertwined quite a lot: Changing one piece does have consequences in
other places -- you have to rework pretty much the whole design.

I don't know enough details to say for sure, but I'm rather positive
that even if the constructor was the *only* thing we don't want, it
still would make Coyotos unsuitable for us...

> Yes, the system provides a service out of the box that provides DRM
> memory which might be a step towards DRM content protection. I do not
> like the feature but I have not seen a secure system design without
> such feature, either.

Well, as I explained, we believe that we can build a system providing
the kind of security *we* are interested in, without such mechanisms.

> >  > If you cannot do something as root you cannot do it at all on the
> >  > system
> >
> >
> > This is just wrong. Think of BSD secure levels for example: Certain
> > things are protected when the system is running in the normal mode,
> > but the administrator can still change them by starting it in a
> > different secure level.
> 
> You can shut down Coyotos and look at the on-disk image. As going to
> less secure level from a more secure level can be only done by
> rebooting there is not much difference here.

As I said, SElinux uses a different approach, which doesn't require
rebooting AFAIK; I only used the secure levels as an example to refute
your claim that root permissions and admin permissions are inherently
equivalent.

More importantly, the fact that you can theoretically manipulate the
disk image of a Coyotos installation, doesn't mean it's actually
feasible in practice.

This is a common theme in your arguments: You always say that this is
possible and that is possible, totally ignoring the question how
realistic things actually are. But as I already pointed out at the
beginning of the discussion, this is the only really interesting
question: because in theory, you pretty much can do anything you desire
on pretty much any system, if you invest enough effort.

What really distinguishes designs is only *how hard* certain things are
with one design or the other. A good design is one that makes the things
we are interested in straightforward; the properties we want to see
natural.

> > No, this is all that *you* seem to be interested in. Other people
> > expect better integration between applications -- there is a reason
> > things like dbus were created.
> 
> I do not know why dbus was created and what problems it is trying to
> solve. And I have no idea why a word processor would need to
> communicate with any other application for example. There are
> clipboards but these are not in dbus so I really don't know any use
> case for typical application communicating through dbus with another
> one.

So you don't see the reasons. Great. "I don't see it, so it's not
there!"...

> > You are missing the point: There would still be no integration
> > between applications running in the UNIX environment, with dbus and
> > all, and "native" applications running in an environment knowing
> > nothing about dbus.
> 
> Why so?
> 
> dbus uses streams for communication, and there sure is need for
> streams in any system. I do not see how this does not fit.
> 
> I would want to examine dbus and see if it can be modified to make
> better use of the system or if it just tries to work around some
> problems that could be solved differently on non-unix system but for
> start there is no reason why its socket cannot be used by any
> application.

You are still missing the point. Of course you *can* make the "native"
applications communicate with UNIX applications using dbus, if you
implement dbus support -- just as you can implement any other UNIX
facility to improve interaction with UNIX applications... But then, you
end up implementing all these horrible ill-designed insecure UNIX things
you wanted to get rid of in the first place!

(From what I heard, dbus fits in with this category quite well.)

Also, you are again ignoring the question of feasibility...

There is no way you can have good integration of UNIX applications
without using the UNIX facilities. I stand by my claim that when good
integration of UNIX applications is top priority, the only useful
approach is building around a POSIX environment. (As a reminder, this is
not the only reason why we are doing so; it's just one of them.)

-antrik-