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

[Michal Suchanek]

2008/12/12  <olafBuddenhagen@gmx.net>:
> Hi,
>
> It's a bit strange to answer here, as part of the discussion seems to
> have gone on off-list. Yet there are a few things in your mail that even
> lacking context I feel compelled to set straight...
>
> On Mon, Dec 08, 2008 at 02:19:34PM +0100, Michal Suchanek wrote:
>> 2008/12/8 Arne Babenhauserheide <arne_bab@web.de>:
>> > Am Freitag 05 Dezember 2008 12:40:32 schrieb Michal Suchanek:
>
>> Sure, and you might also want control its memory usage, and that it
>> cannot access the memory of other processes (because it is no debugger
>> it has no business doing so).
>
> In the hierachical security model we proposed, a process is protected
> from other processes, but *not* from it's parent. Whether the parent
> actually wants to debug on not -- it always has the permission to do.
> And we believe this ability to be fundamental for any system that
> respects user freedom.
>
>> And once you have access control that actually works you can turn it
>> into DRM by giving up some rights so some system service that
>> implements DRM.
>
> Yes, as I explained in my last mail on that subject, it's technically
> possible to run a service outside the user's control to implement DRM.
> But -- as I also explained in that mail -- it requires explicit action;
> more exactly, it requires the administrator actively taking part in the
> treachery against the user.
>
> This is very different from an EROS-like system, where any process
> started by the user and running on the user's resources, can implement
> effective DRM whenever it wishes to. The mechanisms for that are
> provided by the system by default, and neither the user nor the
> administrator can prevent it.
>
> If you are not able to see the difference, I can't help you.

This is not true. The system just provides the service by default but
unless you give your program access to the service (or in EROS it
might mean to build a constructor that runs the program in such way)
the program cannot magically use DRM on its own.

Again, you can modify the system to not provide the service (difficult
for EROS as many of its core servers probably rely on it), not give
the program the permission, or design a system on top of the kernel
that does not provide the option (allows an administrator to inspect
anything at any time).

It's just a difference in the default setup in my view.

I see that the EROS or Coyotos as a whole does not fit the
requirements of a GNU system but I think reusing some basic parts is
no worse than using any other kernel.

>
>> Then you are out of luck actually. Because "secure enough to implement
>> DRM" is less than "secure enough to prevent as many breakins as
>> possible".
>
> This is bullshit. Not every kind of security automatically enables
> effective DRM. I already explained why, and I won't explain again.

I do not see why. DRM is just a security policy that can be built on
top of any security that is actually usable.

>
>> "Better than POSIX" is actually very low standard in my view.
>
> This is easy to say, as we know the shortcomings of POSIX well.
>
> Yet I bet that if you created a new set of APIs from scratch, you would
> make just as many errors as the UNIX creators did -- only different
> ones.

There sure would be problems but the major problem with POSIX is that
it is not designed. It is just a collection of things that happen to
work on most systems.

>
>> > So we are now talking redesigning most applications.
>>
>> Yes, most applications are unreliable, insecure, miss important
>> functionality, and have poor UI.
>
> Good luck reinventing the world.
>
> I hope you understand that this is not what we are interested in.

I understand that redesign of every poorly written application is not
part of the Hurd project. I just do not see the application worth
tailoring the system for them.

>
>> > But I know that just the changes Gentoo ebuilds make to get programs
>> > running in the environment they are designed for can become quite
>> > mmuch work, and I get the impression of quite much pain when I think
>> > about porting nontrivial stuff to a pure capabilities system.
>>
>> You experience pretty much the same pain porting stuff to the Hurd
>> which takes POSIX to the letter and does not implement certain
>> optional aids on which many POSIX programmers like to rely.
>
> Sorry, this is just utter bullshit.
>
> Presently nearly 60% of all Debian source packages (that is more than
> 4600 packages) build on the Hurd -- and most of them actually work.
>
> The majority of these packages builds out of the box, without any
> changes. (We sure did not fix 4600 packages by hand...) Some needed more
> or less trivial patches (a few hundred perhaps), and a handful required
> more serious porting.
>
> (Of the remaining 40%, more than half are waiting on other packages they
> depend on; less then 20% of packages actually failed building. If the
> build dependencies were resolved, it is to expecty that again 60% of the
> dependant packages would build fine. All in all, we can extrapolate to
> about 25% of all packages failing on their own accord -- and again, most
> of them probably require only trivial patches to fix.)
>
> I want to see you pull this with a system that doesn't implement POSIX
> natively...
>

And how many of them use any Hurd specific features? If all you want
is the application compiling and running on the system then you can do
that on any system that provides POSIX compatibility in one way or
another.

Thanks

Michal