bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A niche for the Hurd - next step: reality check


From: Michal Suchanek
Subject: Re: A niche for the Hurd - next step: reality check
Date: Wed, 26 Nov 2008 22:56:10 +0100

2008/11/25  <olafBuddenhagen@gmx.net>:
> Hi,
>
> On Sun, Nov 23, 2008 at 04:20:01PM +0100, Michal Suchanek wrote:
>
>> Well, you don't stop using knives because people can be threatened and
>> killed with them, do you?
>
> Please, don't start that discussion again, with all it's absurd
> comparisions about guns being good for shooting horses and whatnot. This
> has nothing to do with the Hurd.
>
> The situation is really quite simple: A system designed to support use
> cases like DRM is unquestionably bad from a GNU viewpoint -- not only
> because it helps DRM specifically, but because the whole concept of a
> program hiding something from the user is fundamentally against GNU
> philosophy.
>
> You will never see anything like that in the Hurd, end of discussion.

Unfortunately this is not so easy to discard.

If you have non-trivial security you can run two processes and verify
that process A cannot modify anything that would affect execution of
process B.

On a single user system the user might be in total control of all
system memory. However, on system that supports multiple users there
should be a service that guarantees that resources (like storage)
provided to one user are not accessible to other users until the user
explicitly gives them permission to do so.
Once this service is provided it is also possible to extend the
service to support DRM. The protection that is provided between
different processes or different users can also work for DRM
processes. Here a process would request that part of the memory which
was granted to it by the user (user shell or another process that
executed the DRM process) be no longer accessible by any other process
- hence any process the user might execute.
Of course, the extension might not be implemented or the process might
not have permission to use it but then the process might refuse to run
in that case.
For the DRM to be effective it must be possible to verify that the
system that implements the protection is known to really fulfill the
promise. Hardware cryptographic devices are provided for that, and are
put an many (most?) current mainboards. It might take some effort to
implement the verification but again it would be easier for system
built of multiple components  where some of the components aren't
critical for security than for current monolithic systems.

To sum it up security is just security. There is no security for the
user or security against the user.

There might be security policy that works for or against the user but
it ultimately uses the same security principles.

And one of the security policies that are designed to remove many
rights from many users if implemented correctly is what is called DRM.

Thanks

Michal




reply via email to

[Prev in Thread] Current Thread [Next in Thread]