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

[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-