chroot issues and http://tri-ceps.blogspot.com/2007/07/theory-of-filesystem-relativity.html

[Richard Stallman]

     * Simply don't allow setting passive translators inside a chroot at
       all. After all, chroot is only for UNIX compatibility, and
       translators are not a UNIX concept...

This doesn't do the job.  Suppose someone creates the passive translator
or firmlink in the directory, and later you do a chroot to that directory.
The problem will happen.

In other words, this is not about creating a firmlink while chrooted,
it is about the existence of a firmlink inside the chroot directory.

     * Allow setting passive translators, but only temporarily, not
       storing them in the underlying filesystem. When accessing the
       translated node, the translator is started by the chroot.

I don't really follow that.

     * Store the passive translator, but also store the chroot
       information; and only start the translator if the node is accessed
       from within the same chroot.

The next one is clearly better than this one.

     * Store the passive translator and the chroot, and whenever the node
       is accessed, run the translator in a matching chroot. This might be
       the most elegant solution.

This doesn't seem to address the case that someone else makes a
firmlink in the directory that you are chrooted to.

     * Last but not least, we could simply allow setting passive
       translators from within a chroot normally like it happens now, but
       when a translated node is accessed, the translator started would
       run in the context of the process accessing it -- which is
       different for a chrooted process than for a normal one.

That one makes sense.  I see another that also makes sense:

     * If a firmlink points to a place outside the chroot, treat it as if
       it pointed to a nonexistent file.

That way, it can never point to the "wrong" file.


The main question is, does anyone know of any flaws in these solutions?

[Michael Casadevall-6]

On Mon, 2007-09-10 at 19:55 -0400, Richard Stallman wrote:
> * Simply don't allow setting passive translators inside a chroot at
>        all. After all, chroot is only for UNIX compatibility, and
>        translators are not a UNIX concept...
>
> This doesn't do the job.  Suppose someone creates the passive translator
> or firmlink in the directory, and later you do a chroot to that directory.
> The problem will happen.
>

In addition, firmlinks are needed for full support for features like
networking in chroots. You need to make a firmlink
from /server/sockets/2 to *chroot*/server/sockets/2 if you want the
network to work. In addition, due to Hurd architecture, if we want full
network support inside a chroot, we'll need to either redo how
networking is done in heard (get rid of /server/sockets/2), or provide a
mechanism to share servers/sockets/etc, between the chroot jail and the
base system. I think the same problem exists in sub-Hurds, although
someone with more experience will have to comment.

> In other words, this is not about creating a firmlink while chrooted,
> it is about the existence of a firmlink inside the chroot directory.
>
>      * Allow setting passive translators, but only temporarily, not
>        storing them in the underlying filesystem. When accessing the
>        translated node, the translator is started by the chroot.
>
> I don't really follow that.
>
>      * Store the passive translator, but also store the chroot
>        information; and only start the translator if the node is accessed
>        from within the same chroot.
>
> The next one is clearly better than this one.
>
>      * Store the passive translator and the chroot, and whenever the node
>        is accessed, run the translator in a matching chroot. This might be
>        the most elegant solution.

>
> This doesn't seem to address the case that someone else makes a
> firmlink in the directory that you are chrooted to.
>
>      * Last but not least, we could simply allow setting passive
>        translators from within a chroot normally like it happens now, but
>        when a translated node is accessed, the translator started would
>        run in the context of the process accessing it -- which is
>        different for a chrooted process than for a normal one.
>
> That one makes sense.  I see another that also makes sense:
>
>      * If a firmlink points to a place outside the chroot, treat it as if
>        it pointed to a nonexistent file.

This should only be the case for passive instances of the firmlink
translator. The active one should be allowed to point outside the jail
if needed.

>
> That way, it can never point to the "wrong" file.
>
>
> The main question is, does anyone know of any flaws in these solutions?
>
>

[olafBuddenhagen]

Hi,

On Mon, Sep 10, 2007 at 07:55:13PM -0400, Richard Stallman wrote:

>      * Simply don't allow setting passive translators inside a chroot
>      at all. After all, chroot is only for UNIX compatibility, and
>      translators are not a UNIX concept...
>
> This doesn't do the job.  Suppose someone creates the passive
> translator or firmlink in the directory, and later you do a chroot to
> that directory. The problem will happen.
>
> In other words, this is not about creating a firmlink while chrooted,
> it is about the existence of a firmlink inside the chroot directory.

I don't think this is a problem. Such a backdoor created from outside
the chroot can very well be intentional (see the /server/socket/2
example mentioned by Michael Casadevall in the other reply); the problem
is only to prevent the chrooted process to create a backdoor *for
itself*.

>      * Allow setting passive translators, but only temporarily, not
>      storing them in the underlying filesystem. When accessing the
>      translated node, the translator is started by the chroot.
>
> I don't really follow that.

Currently, if a chrooted process sets up a passive translator, it is
stored directly to the underlying FS, just the same as if the process
wasn't chrooted at all. Thus the chrooted process can create a firmlink
(or other translator) living outside the jail and creating a backdoor
for the jailed process.

To fix this, we need to handle setting of passive translators specially,
if it is done by a chrooted process. The first suggested solution is the
simplest way to specially handle them: Just say no to any attempts at
setting a passive translator from inside a chroot.

If we want to allow setting them however, we have to make sure that the
translators created this way are handled specially later on. When
storing them on disk, we somehow also need to store the chroot
information. The variant suggested above would avoid that problem by
simply never storing them to disk; the FS would only remember the
chrooted translator while it is active, and drop it when the chroot (or
the FS) terminates.

I'm aware that this wouldn't be very elegant; I only mentioned it for
completeness. The next two variants suggest ways to handle permanently
storing chrooted translators.

>      * Store the passive translator, but also store the chroot
>      information; and only start the translator if the node is
>      accessed from within the same chroot.
>
> The next one is clearly better than this one.
>
>      * Store the passive translator and the chroot, and whenever the
>      node is accessed, run the translator in a matching chroot. This
>      might be the most elegant solution.
>
> This doesn't seem to address the case that someone else makes a
> firmlink in the directory that you are chrooted to.

No problem here -- as I pointed out above, translators created from
outside the chroot don't really need special handling.

>      * Last but not least, we could simply allow setting passive
>      translators from within a chroot normally like it happens now,
>      but when a translated node is accessed, the translator started
>      would run in the context of the process accessing it -- which is
>      different for a chrooted process than for a normal one.
>
> That one makes sense.  I see another that also makes sense:
>
>      * If a firmlink points to a place outside the chroot, treat it as
>      if it pointed to a nonexistent file.
>
> That way, it can never point to the "wrong" file.

Well, as I pointed out above, the interesting case are translators
created from within the chroot. How would you handle that? It would be
possible to set a firmlink inside the chroot, but when trying to access
it, it would say "file not found"? I think that would be less useful
than my first (most simplistic) solution: Simply not allowing to set
them in the first place.

-antrik-

[Richard Stallman]

    Well, as I pointed out above, the interesting case are translators
    created from within the chroot. How would you handle that?

I was thinking about a different problem.  I thought you were, too.

[Alfred M. Szmidt]

I think people are concentrating on the outdated chroot model far to
much.  The Hurd already has a immensly secure way to create a secure
box from which one cannot escape, it is called a sub-hurd.

[Richard Stallman]

    I think people are concentrating on the outdated chroot model far to
    much.  The Hurd already has a immensly secure way to create a secure
    box from which one cannot escape, it is called a sub-hurd.

It would be useful to make a precise proposal to eliminate chroot as a
mechanism and use sub-hurds to do the same job.  Then people could look
for flaws in it and we could see if it really works.

[Alfred M. Szmidt]

       I think people are concentrating on the outdated chroot model far to
       much.  The Hurd already has a immensly secure way to create a secure
       box from which one cannot escape, it is called a sub-hurd.

   It would be useful to make a precise proposal to eliminate chroot as a
   mechanism and use sub-hurds to do the same job.  Then people could look
   for flaws in it and we could see if it really works.

I'm not sure what such a proposal would look like, or how one would
find flaws in it.  A sub-hurd is a completely seperate system running
within a system.  It has a completely seperate space, and does not
share anything with the host system, not even devices (hence the need
to somehow poke holes in a sub-hurd so devices can be shared).

It is like emulating a system within a system, but without emulating
the hardware.  Where as a chroot simply changes where / is located (in
very simplistic terms).

[Richard Stallman]

       It would be useful to make a precise proposal to eliminate chroot as a
       mechanism and use sub-hurds to do the same job.  Then people could look
       for flaws in it and we could see if it really works.

    I'm not sure what such a proposal would look like, or how one would
    find flaws in it.

How would you build a sub-Hurd for real practical use, and
what sort of holes would be needed to make it work
in a case where you might have used chroot?

[Alfred M. Szmidt]

          It would be useful to make a precise proposal to eliminate
          chroot as a mechanism and use sub-hurds to do the same job.
          Then people could look for flaws in it and we could see if
          it really works.

       I'm not sure what such a proposal would look like, or how one
       would find flaws in it.

   How would you build a sub-Hurd for real practical use,

More or less like a normal chroot, for a chroot one tends to do the
following:

mkdir foo
copy basic system to foo
chroot foo

for a sub-hurd, the process is similar:

create a file, and mount it on foo
copy basic system to foo
sub-hurd foo

   and what sort of holes would be needed to make it work in a case
   where you might have used chroot?

One would have to allow access to /servers/socket/2 from the
underlying system to be able to get networking, and probobly other
files as well depending on what one wishes to use the sub-hurd for;
like block devices, normal files, etc.

We would need to modify sub-hurds so that when we start our sub-hurd
we can say that /servers/socket/2 in the sub-hurd should forward all
messages to /servers/socket/2 in the underlying system.

[Richard Stallman]

    One would have to allow access to /servers/socket/2 from the
    underlying system to be able to get networking, and probobly other
    files as well depending on what one wishes to use the sub-hurd for;
    like block devices, normal files, etc.

    We would need to modify sub-hurds so that when we start our sub-hurd
    we can say that /servers/socket/2 in the sub-hurd should forward all
    messages to /servers/socket/2 in the underlying system.

Has anyone tried actually writing software to create a sub-hurd for
practical uses?  I think that would be a very useful thing to do.

It would be nice to write a special virtual partial copy file system
that a sub-hurd can use, to avoid the need to actually copy the files.

What exactly this should do, to get the job done and be secure, is the
question that we can answer by trying to really implement this.

[Alfred M. Szmidt]

       One would have to allow access to /servers/socket/2 from the
       underlying system to be able to get networking, and probobly
       other files as well depending on what one wishes to use the
       sub-hurd for; like block devices, normal files, etc.

       We would need to modify sub-hurds so that when we start our
       sub-hurd we can say that /servers/socket/2 in the sub-hurd
       should forward all messages to /servers/socket/2 in the
       underlying system.

   Has anyone tried actually writing software to create a sub-hurd for
   practical uses?  I think that would be a very useful thing to do.

I do not understand, sub-hurds are easy to create.  You don't need any
special software for them.

   It would be nice to write a special virtual partial copy file
   system that a sub-hurd can use, to avoid the need to actually copy
   the files.

True, this applies to chroot as well.

   What exactly this should do, to get the job done and be secure, is
   the question that we can answer by trying to really implement this.

It is already implemented, and has been implemented for the past 10
years.

[Richard Stallman]

       What exactly this should do, to get the job done and be secure, is
       the question that we can answer by trying to really implement this.

    It is already implemented, and has been implemented for the past 10
    years.

Is there an application that really uses a sub-hurd?

[Alfred M. Szmidt]

   Is there an application that really uses a sub-hurd?

It is used mostly for debugging a newly created system, seeing that
all translators start, and debugging early start up code using gdb.

But since you cannot escape a sub-hurd currently, it has limit use;
one cannot run for example a web server inside a sub-hurd for security
reasons, since you cannot send things outside of the sub-hurd (no
access to the network).

[Alfred M. Szmidt]

It just occured to me that another way to allow a sub-hurd to
communicate outside of its enviroment is to run a server outside the
enviroment, that listens and intercepts communication, and injects
messages into the sub-hurd enviroment.  This method I think is a bit
more hurdish, but I do not know exactly how feasible it is, it might
be very slow.

[Richard Stallman]

    But since you cannot escape a sub-hurd currently, it has limit use;
    one cannot run for example a web server inside a sub-hurd for security
    reasons, since you cannot send things outside of the sub-hurd (no
    access to the network).

Now we are getting at the real issues.  For most purposes, we would
need the sub-hurd to allow certain limited ways of writing data out of
the sub-hurd.

Would you like to work on implementing such facilities for sub-hurds?

    It just occured to me that another way to allow a sub-hurd to
    communicate outside of its enviroment is to run a server outside the
    enviroment, that listens and intercepts communication, and injects
    messages into the sub-hurd enviroment.

I do not really understand what that means.  Could you describe
it in more detail and more concretely?

[Alfred M. Szmidt]

       But since you cannot escape a sub-hurd currently, it has limit
       use; one cannot run for example a web server inside a sub-hurd
       for security reasons, since you cannot send things outside of
       the sub-hurd (no access to the network).

   Now we are getting at the real issues.  For most purposes, we would
   need the sub-hurd to allow certain limited ways of writing data out
   of the sub-hurd.

   Would you like to work on implementing such facilities for
   sub-hurds?

Not enough hours in the day for this, maybe someone else would like to
take a crack?

       It just occured to me that another way to allow a sub-hurd to
       communicate outside of its enviroment is to run a server
       outside the enviroment, that listens and intercepts
       communication, and injects messages into the sub-hurd
       enviroment.

   I do not really understand what that means.  Could you describe it
   in more detail and more concretely?

Since one can access all processes that are running in a sub-hurd from
the main system (say, using gdb), one could have a special program,
that listens to the messages that process sends.

Now say that you wish to allow network communication to be allowed
from the sub-hurd, you'd attach this `proxy server' to the network
stack process that is running within the sub-hurd.  The proxy server
would then listen, and forward all communication (at the same time
maybe sending modified messages) to the real network stack process
(the one in the main hurd).

I hope this explains the general idea, how one would go about actually
implementing it (let alone if it is really possible) is a different
story.  A good first step would be to hack GDB so that it can trace
(this is easy), and modify messages (this is harder).

Happy fluting.

[Richard Stallman]

    Since one can access all processes that are running in a sub-hurd from
    the main system (say, using gdb), one could have a special program,
    that listens to the messages that process sends.

    Now say that you wish to allow network communication to be allowed
    from the sub-hurd, you'd attach this `proxy server' to the network
    stack process that is running within the sub-hurd.  The proxy server
    would then listen, and forward all communication (at the same time
    maybe sending modified messages) to the real network stack process
    (the one in the main hurd).

This method might serve, but it would take substantial work to build
useful kinds of communication on top of this mechanism.  Would someone
like to try implementing that?

This is work that any of you could do
without waiting for anyone else to do anything.