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!
http://www.solucorp.qc.ca/miscprj/s_context.hc
This archive was generated by hypermail 2.1.4 : Mon Aug 19 2002 - 12:01:00 EDT