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

[Michal Suchanek]

Hello

2009/1/3  <olafBuddenhagen@gmx.net>:
[...]
>> 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.

Yes, I would like to see such system. As of now I do not feel
capabable of deigning one myself nor has anybody designed one I am
aware of.

>
>> >  > 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.

I do not know if an offline debugger will be part of the Coyotos.

Only when the on-disk image format is set we can talk about how it
does or does not make such debugger hard to write. However, it will
probably not make it difficult because when the system is powered on
it has to be reloaded from the on-disk image and later the on-disk
image has to be updated with current snapshots.

Still you are ignoring feasibility yourself. You say that since the
Hurd has Scheme bindings you can write cross-platform customizations
and fend off my reqeust that Hurd be completely rewritten in scheme
for such customizations to become feasible with something like "the
parts that people will like to customize will be eventually
rewritten".

So in case of Coyotos if such debugger is not available and it is
important for somebody they can write it and/or modify their
installation so that they can get memory access while the system is
running.

>
>> > 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!"...

For me there is not. If you use your text processor in some different
way that would require dbus integration then you can perhaps enlighten
me.

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. I imagine EMACS users
would perhaps like to replace their OS with EMACS but fortunately that
did not happen.

There's a reason why only necessary features are included in software.
And that's feasibility of writing and using such software.

>
>> > 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.)

That's why I say that before porting dbus I would consider what dbus
buys me and if there is another way how I could get the same
functionality.

However, even running a horrible UNIX application you still get
improved security. The communication is really restricted to the
single pipe, applications cannot write each others memory at random,
and they should not get access to random files which you are not using
either.

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

I haven't looked at dbus so I have no idea how horribly it is written
and how hard it is to port to another system if it is really useful
for anything.


Thanks

Michal