Re: How to add confinement to the Hurd?

[Marcus Brinkmann]

At Sun, 30 Apr 2006 19:56:05 -0400,
"Jonathan S. Shapiro" <address@hidden> wrote:
> > Assuming that no legitimate use case is found, and that you are right
> > that introducing this feature means a fundamental shift in the
> > over-all system design, then the answer is clearly that the patch
> > would be rejected for technical reasons, independent of any political
> > evaluation.
> 
> Yes. I understand this. But it does not answer the question. Pierre is
> asking whether your political objections are also decisive independent
> of the technical argument.

I know better than to answer a speculative question in such a heated
debate.  You can not expect me to make a decision here on speculative
grounds that has to be made by the Hurd project maintainers
collectively on factual grounds in the future.  Plus, the GNU project
also has something to say about that.

> You  write that you do not know a technical argument that decisively
> requires true confinement.

In the context of the GNU Hurd, yes.  I do know some use cases which I
have no interest in supporting (with a varying degree :).

> We will certainly work to find one. But if we
> *fail* to find one, this is an insufficient reason to reject such a
> foundational mechanism.

You are omitting the other half of my argument, where I said that I
have good reasons to belief that inclusion of this feature is harmful
(based on the use cases that _do_ exist), and that in fact there is
reason to belief that it has properties which make it intrinsically
unfit for a free software operating system.

You do not need to follow my arguments.  At this point, you clearly do
not.  But, you have at least to give me credit for being consistent
and rejecting a feature which I feel violates an important design goal
(user freedom, which I have not yet formally stated, but will), _and_
which is proposed to be included on the pure speculation that it may
be useful in the future, _but_ with the full knowledge that it is
harmful in the short and medium run.

I have learned too much about principle-based operating system design
from you to make such a leap of faith ;)

> Even if other mechanisms can apparently achieve
> similar results, those other mechanisms will not have the strength of
> formal foundations that the confinement mechanism already has today. We
> will be unable to reason about the correctness of those systems --
> merely to get back to where we stand today with confinement in this
> regard will be more than a decade of work.

This is not true.  Because the trivial confinement property still
holds true, you can still apply the same tools of reasons that you can
in the EROS system.  What you can _not_ do is to use certain design
patterns to construct certain types of confined applications that hide
information.

The hierarchical system structure, induced by the exclusive
parent-child relationship, is a very strong property, and I predict
that it will be sufficient for our needs.  The few exceptions where we
have to make calls to non-confined services will _by nature_ be
unconfined, because the service they implement is an unconfined
service.  This is not different from EROS either.

> Therefore, I would argue: unless there is an overwhelmingly compelling
> reason to *exclude* true confinement, I believe that it should be
> included. I do not want to lose 10 to 15 years of progress on verifiable
> systems unless there is an overwhelming reason to tolerate this.

This warrants a separate discussion.  I think that if we look at the
properties that we can verify or not in the two systems, we will find
out that, again, we are looking at a certain number of use cases for
which the need in the context of the GNU Hurd has yet to be
demonstrated.

Thanks,
Marcus