Re: Hurdish applications for persistence

[Marcus Brinkmann]

At Mon, 10 Oct 2005 23:51:24 +0200,
Marcus address@hidden de wrote:
> 
> 1. Passive translators

Alfred's confusion leads me to believe that maybe this example (or
rather: its presentation) is not as good as I hoped it is, simply
because it contains too many separate issues at once.  All of these
issues are important, but only one was the motivation for this example
in the context of persistence.

First, the chroot example is about some form of confinement.  The idea
behind confinement is that I can provide some selected, narrow
authority to a confined task, and get some guarantee back from the
system that the confined task can not elevate its authority.  Although
confinement is an important concept and critical in building a secure
system, my motivation for this example was a different one: I wanted
to show how the activated translator is different from the passive
translator.  For this, I needed an example where the difference
actually matters.  If the filesystem and the process accessing it have
the same root directory it is not apparent that the acticated
translator gets its root directory from the wrong source.

Second, there is a security problems with passive translators on the
Hurd.  This security problem can be addressed, as Alfred pointed out,
by either removing the circumstances of the problem, or by
removing/disallowing passive translators alltogether.  This is true,
but it misses something obvious: That the idea behind passive
translators is a good and useful one.  The problem is not that the
concept of passive translators is bad.  In fact, as a feature, it is
quite powerful in the context of the Hurd.  It is the implementation
that is problematic.  So, my mail was not about removing passive
translators without a substitute.  Quite the opposite, my motivation
was to either preserve them or, if that is not possible, explore a
design where they are unnecessary, because the goal they try to
accomplish is achieved by other means.

Third, it is absolutely critical to understand what makes it hard to
preserve the passive translator concept.  I didn't make this very
clear in my original mail.  The filesystem which wants to activate a
passive translator is in a dilemma: It is supposed to start a task on
behalf of a user (I will explain next why it can't punt this work back
to the user directly), but it has no way to check what authorities
that user has.  For example, if the user has a capability for the root
directory of the system or not.  Now, if the process using the
filesystem would run under the same user ID as the file owner of the
passive translator node, the filesystem could just punt back the
activation of the translator to the caller.  But passive translators
can be activated by _any_ user who has read access to the directory in
which the passive translator node is contained, not only by the file
owner.  Thus, the filesystem has nobody to punt the work to.  It is
this dichitomy of translator creation and activation that is exploited
by the chroot example as well.

The filesystem has---in general---absolutely no reasonable way to
create _proper_ initial capabilities for the activated translator.  If
you think about this problem, you may be able to come up with specific
examples where you can work around this.  My negative result so far is
that the filesystem simply can not do the job we ask from it, in a
very fundamental way.

At this point, you might want to think about more clever designs.  For
example, every user could register a "translator activator" server
with the filesystem.  When the filesystem is supposed to activate a
translator, it could ask the file owner's translator activator to do
the activation.  This would at least ensure that no authentication is
leaked at the user ID level.  You would end up with a system that is
comparable in (in)security with Unix, assuming you have a careful
system administrator.  I think that would be development in the wrong
direction, but I mention it here for completeness.

Fourth, and this is what my mail was about, there is a rather simple
solution (ok, let's say _locally simple_), which achieves two
objectives: It fully avoids all these complexities, and second, it
doesn't give up on the original goal that server settings are
preserved across reboots.  This solution is to have a persistent
system.  It achieves these two objectives in an almost trivial way: If
a server is started actively, it is always started by some task which
has to provide it with the necessary authority.  The filesystem does
not do this on behalf of anybody.  And, if a server is not shut down,
it doesn't need to be restarted.

I should add a note why I think it is important to not let go of the
original goal behind passive translators.  Beside the advantages we
already know about, in a secured system you have the additional
advantage that you only need to instantiate the server _once_.  So you
only have the problem of establishing and verifying the necessary
authorities _once_, which can be a difficult problem.

Thanks,
Marcus