Re: Hurdish applications for persistence

[Marcus Brinkmann]

At Thu, 13 Oct 2005 00:41:55 +0200,
Alfred M Szmidt wrote:
> 
>    You claim so, but you offer no pudding.  
> 
> I prefer to keep my pudding to my self.  Anyway, you can use fchdir(),
> various forms of ../, and recursive chroots.  And I would have
> suggested mknod(), but see bellow..

Good luck to run chroot() or mknod() as non-root!

We already knew that Unix offers no security against the super user.

>    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:
> 
> Since abusing device nodes is similar to abusing firmlinks, one could
> simply not provide settrans in a chroot.  Given mknod, one can escape
> chroot, and given firmlink/settrans, one can also escape a chroot by
> doing the same thing.

It's not the same, because mknod in Unix is restricted to root, while
we want to believe in the Hurd that settrans can freely be used by
non-root users.  In fact, Beside not providing settrans, you would
also have to provide absolutely no way to construct executable files
with arbitrary binary data, which includes no bash shell and chmod,
for example.  Because otherwise I can simply create a settrans binary:

echo $'\x7f\x45\x4c\x46 [...]' > settrans
chmod +x settrans

But I congratulate you, you have found yet another way to increase
security by disallowing sharing rather completely.

> If you can put a random program in a chroot, you will _always_ find a
> way to break out of it.  And it is simply not worth fixing it.

You are dead wrong until you prove otherwise.  That is, unless you
talk about the Hurd, of course.

>    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.
> 
> And I still consider chroot as a bad example, and consider sub-hurds
> (or some form of them) far more flexible than chroot().

And this although the subhurd is the most inflexible "solution" of
them all, as it offers complete separation and no sharing at all.  I
marvel at your understanding of the word "flexible", but will leave it
at that.

You have at least added the qualifier "some form of them".  As said
previously, this is exactly what needs consideration.  It's not
something that can be invoked by a magic hand wave.  This "some form"
is not going to magically pops up into existance.  It requires careful
consideration and design, and, yes, some form of a working "chroot"
(which I will happily give it another name as to not confuse it with
the Unix chroot() call.  Let's say chr00t.).

>    I don't think it is possible to fix passive translators in the
>    Hurd.
> 
> The thing is that I don't think it is worth the trouble to fix them.
> It is to much of a headache, and it doesn't give you that much anyway,
> since you can solve the problems that come with passive translators in
> other ways that are simpler.

We finally find something we agree upon, it's not worth the trouble to
fix passive translators (certainly I believe so, as I think they can
not be fixed at all).

Then please let me ask you a question: What do you want to replace
them with?  The Hurd in its current incarnation deals very poorly if
you remove the passive translators from the system.  For example, you
will end up without a pipe and without a network, and without any
device files.

Mmh, maybe you want to restrict settrans -p to the superuser.  That's
a solution which works.  It's the traditional Unix response.

Or maybe you want to remove passive translators completely and just
start active translators from the boot scripts (and login scripts).
This works as well and also fits well with the Unix world.  Daemons
are started this way.

In either case, the user would be stuck with active translators only.
Such a solution would take away some convenience, but it would put the
Hurd back in competition with other Unix systems in terms of security
and configurability.

This approach works because it is easy in Unix (and thus the Hurd) to
prepare the authorization that a user has in the system at bootstrap:
Just give them their user ID, and all the authorization they have is
in place.  This setup however starts to become quite inconvenient once
you start to really secure your system in two ways: You handle user
authority in a fine-grained manner, and second: You want some
certainty that the authorization is correctly preserved across reboots
(ie, some kind of proof that the boot procedure did not introduce
positive changes to the authorization of a user).

In this case, reinstantiating your active servers at boot or login
time is a serious pain in the ass, and may even be impossible,
depending on the types of objects you need.

So, I think that using boot scripts works reasonably well in the Unix
world (and thus the current Hurd world), but that it is a rather
inflexible approach which has security flaws (again, flaws that don't
matter in an insecure-by-design system anyway).

Thanks,
Marcus