[vserver] Re: [useradd] Adding user fails in vserver

About this list Date view Thread view Subject view Author view Attachment view

From: Jacques Gelinas (jack_at_solucorp.qc.ca)
Date: Wed Feb 06 2002 - 13:30:10 EST

On Wed, 6 Feb 2002 14:46:10 -0500, edward_at_paradigm4.com.au wrote
> On Tuesday, 5 February 2002 at 13:51, Jacques Gelinas wrote:

> > The problem is not the first chroot (the one used to "enter" the vserver). the
> > problem is doing a second chroot while keeping the current directory behind.
> It is my understanding that all the considered chroot exploits ( we are not talking
> about using
> devices and mounting tricks as this capability is disabled in vserver ) are based
> on either
> using file handle that was open before the first chroot, or the current directory
> from
> before the first chroot.

No. chroot exploit may happen after any number of chroot. the trick is not
to beat the current chroot by using left-over resource. The trick is to
setup those resource (open a directory and keep the handle) and then
perform the chroot. Here is how it works

        You have a clean state. No open directory. You current
        directory point to /vservers/v1

        You do chroot ("/vservers/v1");

        At this point, all is clean.

        Then root inside the vserver v1 do this

        int fd = open ("/",O_RDONLY);

        Now fd point to /vservers/v1 effectivly

        chroot ("/tmp");

        Now we are in a chroot inside a chroot. Note that on the kernel
        side, the current process has its root in /vservers/v1/tmp, but
        there is no such a thing as nested chroot. I mean, all the kernel
        knows from now on is that this process has /vservers/v1/tmp
        as its root and it can't tell the difference between a process
        like this one and another process having done

                chroot ("/vservers/v1/tmp")

        right from the root server.

        Now, the process simply do

        fchdir (fd)

        Its current directory is now /vservers/v1. So even if the chroot
        system call had force the current directory to /tmp (/vservers/v1/tmp)
        now, the process current directory is behind the process root. From
        now on, the process can perform file operation behind its root.
        But it is locked into using relative addressing. Whenever it does
        something like

                chdir ("/somedir");
                open ("/x/z/some_file");

        the process root kicks in and the operation is performed in /vservers/v1/tmp.

        So the process only option is to read in the current directory
        (which it could do before the chroot anyway) or in parent
        directory using .. notation. Now, using .. to walk its way to the
        real root, it will meet the /vservers directory and won't be able
        to access it (because of the ctx-6 vfs_permission patch).

> p.s. speaking of open file handles, what about stdin, stdout and stderr of a process
> before chroot
> and after. How is that handled?

There is no restriction in the chroot system call about file handle. For example
a client server system may setup various pipes, then fork and run a not-so-trusted
plugin in a chroot. This would be a perfectly valid usage of chroot.

This is one reason I create the vfs_permission patch. Instead of trying to
fix chroot at all price and annoying those using it with creativity, I came up
with this simple fix.

Currently, the vserver script (and utility) do not enforce any cleanup
of the file handle inherit by parent. So it would be possible to setup
some special fiel handle, and enter a vserver context with them alive.
I would see this as a feature. Currently, if you do

        /usr/sbin/vserver XX enter
        ps ax
        ls -l /proc/PID_of_sh/fd

you see that the shell only has access to the tty.

Jacques Gelinas <jack_at_solucorp.qc.ca>
vserver: run general purpose virtual servers on one box, full speed!

About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.4 : Mon Aug 19 2002 - 12:01:00 EDT