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

[Michal Suchanek]

On 27/12/2008, olafBuddenhagen@gmx.net <olafBuddenhagen@gmx.net> wrote:
> Hi,
>
>  On Tue, Dec 23, 2008 at 12:19:26PM +0100, Michal Suchanek wrote:
>  > 2008/12/22  <olafBuddenhagen@gmx.net>:
>
>
>  > > Well, *we* don't find EROS-like persistence useful for our purpose.
>  > > I never found it useful, as you might remember; and Marcus, who was
>  > > advocating it for a while, finally came to the very same conclusion.
>  > > (After stumbling over some site with various articles explaining the
>  > > issues much better than I can.)
>  > >
>  > > I'm not sure about Neal's current stance.
>  >
>  > I am sure that I do find it useful.
>
>
> And this is relevant, how?...
>
>  I told you that Coyotos is not useful for us; you asked why; I was nice
>  enough to explain. Your preference for a different system design doesn't
>  even come into play here... Coyotos is not useful for us, period.
>
>
>  > The user session is not the top process in any system I know. It is
>  > started by another system service.
>
>
> What do you mean by "top process"?
>
>  The user session is obviously not the parent of all processes -- that
>  just wouldn't work in a multi-user system. But all processes *of the
>  same user* are descendants of the user session.
>
>  Now in Coyotos this doesn't mean much, as the parent doesn't directly
>  create a process, but rather just invokes the constructor. This way the
>  child process can have authority that the parent process doesn't have.
>  And the spacebank mechanism ensures that even though the resources are
>  usually supplied by the parent, it still has no access to the child's
>  memory contents.
>
>  In the hierarchical system we proposed the situation is very different
>  however. Processes are created directly by the parent, so they can't
>  have any additional authority; and the process handing out memory always
>  has full access to it. The user session has full control over all its
>  descendants, and thus all the user's processes.

This system differs from coyotos in that the processes are really
started by their parent, not a system service. That does not seem that
different to me.

In coyotos the tree is very flat, pretty much everything is descendant
of some 'constructor service' but the concept is the same I would
think.

>
>
>  > The 'drm memory' service is an addon which is possible to add to any
>  > system that implements memory protection.
>
>
> In Coyotos, it's not an addon. Any memory can be used for implementing
>  secure DRM; the system provides and relies on the necessary mechanisms
>  throughout. This is precisely my point.

This is only true for the system as a whole. The kernel and space bank
only provides memory protection as any other system would.

>
>
>  > For example, on Linux all the applications running as the same user
>  > can access the memory of each other and root can access all memory. So
>  > on Linux you would need a suid executable and a modification that does
>  > not allow the root user access to all memory. Given that several
>  > extensions for limiting the root account privileges exist (such as
>  > selinux) it should not be too difficult to add this feature somewhere.
>
>
> I don't know much about SElinux etc. However, AFAIK they only limit the
>  power of the traditional root account, but *not* the power of the actual
>  admin.

Since 'root' is the 'administrative account' this is pretty much the same thing.
If you cannot do something as root you cannot do it at all on the
system which is exactly there reason these limitations were introduced
- to not allow infecting the system with viruses or root kits or
breaking it while it's running.

>
>  Coyotos on the other hand is designed in such a fashion that once the
>  system is installed, nobody -- not even the admin -- has full control
>  over all parts of it.

As I understand it it's one of the possible configurations.

You could install a configuration with a 'root' account which would be
certainly useful for debugging or single user systems.

>
>  But I wasn't even talking about that. Even if it *was* possible in
>  Coyotos for the admin to defeat a DRM mechanism, it would still require
>  active intervention to break it; while in the system we proposed it
>  require active intervention by the admin to install it in the first
>  place.
>
>
>  > However, security involving hardware encryption and verification of
>  > system integrity by means of hardware cryptography device can enforce
>  > the 'drm protection'. Some applications might refuse to run on system
>  > that is not known to implement effective protection.
>
>
> As I already said, this is precisely why TPM (remote attestation to be
>  precise) is so dangerous, and why we need to fight it tooth and claw.
>
>
>  > > What I want is a system with only one integral part -- being mostly
>  > > UNIX-compatible and UNIX-like be default, and yet offering many new
>  > > possibilities; more generally, giving the user much more control
>  > > over the environment.
>  > >
>  > > This is what the Hurd provides.
>  >
>  > Thus I find the Hurd unsatisfactory.
>
>
> Yeah, we already gathered this much. In fact, I said myself that in view
>  of your expectations, the Hurd is obviously not the right system for
>  you.
>
>  I wonder, what exactly are you trying to achieve by prolonging this
>  discussion?
>
>
>  > It provides only the ancient broken interface with many inconsistent
>  > APIs to both legacy and native applications, and only allows
>  > introducing new features by manipulating something 'behind the
>  > scenes', outside of the advertised POSIX personality.
>
>
> "allows"? "behind the scenes"? What are you talking about? It is
>  perfectly possible, allowed, *and encouraged* to create alternative
>  interfaces in the Hurd. This is what the Hurd design is all about!
>
>  As I already said, it should be perfectly possible to create a
>  completely new personality, if that's really what you want. It might
>  even become part of the standard Hurd, if it proves useful -- although
>  the main personality will most likely always be the one built around
>  POSIX.
>
>  It's all about focus, not about possibilities.
>
>
>  > Since the new applications should run isolated there should not be
>  > much difference between running a native applications and a POSIX
>  > application inside an isolated POSIX environment once you find out
>  > what support configuration and tools POSIX applications typically
>  > expect.
>
>
> We are talking about different kinds of "isolation".
>
>  Obviously appliactions need to be protected against harmful
>  interference. However, that does *not* mean total isolation. They still
>  can, and should, uses common mechanisms, common interfaces, common
>  services -- integration between different applications is a must. And
>  this is just not realistic if different applications run in completely
>  different environments. Only applications using more or less the same
>  personality can be properly integrated; and if we care about POSIX
>  applications -- which we do -- this personality must be based on POSIX.
>

I am not so sure about that. For example Compozer is available for
both Windows and Linux, and the Linux version crashes on my system so
I run the Windows version inside Wine.

The underlying interface the two binaries use is different. However,
they both show a window on my screen and access the same Documents
folder for opening and saving files.
This is all the compatibility one ever needs for a typical application.

Thanks

Michal