Re: Hurdish applications for persistence

[Marcus Brinkmann]

At Wed, 12 Oct 2005 12:54:59 +0200,
Alfred M Szmidt wrote:
> 
>    It is not true that "chroot is insecure on all platforms".
> 
> All UNIXoid platforms.  There are several ways to break out of a
> chroot on them.

You claim so, but you offer no pudding.  Tell me how a non-root user
can escape a chroot that contains no device nodes, and no suid
binaries on the latest versions of the following systems:

FreeBSD, GNU/Linux, SunOS

> My point is that a chroot() isn't suitable for us (in the current
> situation), and we should use something else instead of doing a full
> rewrite of everything.

Who is "us", and what is the "current situation"?  Finally, what is
"something else"?  I have elaborated at length why the chroot
_example_ matters well beyond the use of chroot.  I thought, and still
think, that the example is a good lever to help to understand the
critical problem of (preserving) the execution environment of servers,
and the question of confinement.

> You are trying to fit the Hurd into POSIX, which is simply the wrong
> kind of thinking.

Let's leave aside that you don't speak for me, and without asking me
you can't know what I am trying to do or not.  What is left is that
you seem to think that trying to confine processes and share narrowly
is to fit the system into POSIX.  That's bizarre.  As you know POSIX
rather well, I can only assume that you don't yet quite grasp what it
means to confine a process and share narrowly.  It certainly doesn't
mean ACL based authentication and an "open()" call that only
understands absolute and relative paths (from one working directory).

I will give you a hint.  What I am trying to do is to explore how the
Hurd can be made really secure.  This requires, among other things,
that the principle of least authority is adhered to.  As Unix
demonstrates, it is very hard (let's admit it and say impossible) to
secure a system where there exists a super user, in fact where users
exist at all, and where authority can not be selectively delegated.

Let's make this more specific.  If I don't want my browser to send my
personal data over the internet, then the best way to achieve this is
to ensure that the browser does not have the authority to access my
personal data, in any way, at all.  It still can access my display
window, my mouse data, an incoming directory for downloads, and a
bunch of other stuff.  To make this work I need to be able to give my
browser a capability to my incoming directory for downloads, and this
capability must not allow looking up ".." to escape the incoming
directory.  In essence, this capability must be "chrooted", pretty
much like the Hurd shadow roots work, in fact.

How is this related to the passive translator scenario?  The passive
translator scenario is an example where the principle of least
authority is violated.  The filesystem gives the passive translator a
capability to the root filesystem that it doesn't need to have, and in
fact: That it _must not_ have if you want to confine a task accessing
that part of the filesystem.

I don't think it is possible to fix passive translators in the Hurd.
The reason is actually quite simple: It is not possible for the
filesystem in general to reconstruct the correct authorities that that
activated translator should have, because there is no way to express
those correct authorities as a byte stream in the Hurd and store them
to disk.  This is finally where persistence enters the picture.

Thanks,
Marcus