Exit from os.chroot()

[support\.intranet]

Hello! I'm writing a small script and I need to call the os.chroot function. The problem is, a few lines below I need to call a program in /usr/bin. Is there a way to exit from the chroot, or to limit the chroot to a single function or thread?
Thanks in advance

 

[Thomas Bellman]

So you need some programs in your chroot: Then put a directory
usr/bin into the chroot directory and bind the system's /usr/bin
there:

mount --bind /usr/bin $chroot/usr/bin

That might not be the best idea... Suddenly the chroot:ed
program has access to the real /usr/bin; and since it likely is
running as root (it was allowed to call chroot()), it can do bad
things to the things in /usr/bin. Even if the process has
relinquished its privileges (which it should!), you will give it
access to unnecessarily many programs, many of which are setuid
or setgid.

It is better to make copies of the needed binaries and libraries,
and *only* them.

Another option
would be to place a statically linked busybox and it's
subprogram links into the chroot

Much better than bind-mounting (or loopback-mounting if you are
on SunOS/Solaris instead of Linux). Of course, assuming that
busybox implements the command the OP needs.

Also remember, a chroot:ing process should permanently relinquish
its privileges as soon as possible after chroot:ing. There are
way too many fun things a root-running process can do even when
chroot:ed, like creating device files or setuid binaries.


All this is of course assuming that the chroot is done for
security reasons. There are other reasons one might want to
run in chroot.

 

[Wolfgang Draxinger]

Hello! I'm writing a small script and I need to call the
os.chroot function. The problem is, a few lines below I need to
call a program in /usr/bin. Is there a way to exit from the
chroot, or to limit the chroot to a single function or thread?
Thanks in advance

No, chroot applies to the whole process and once applied it can't
be reverted. Otherwise the whole idea of chroot being a FS jail
would not work.

So you need some programs in your chroot: Then put a directory
usr/bin into the chroot directory and bind the system's /usr/bin
there:

mount --bind /usr/bin $chroot/usr/bin

The same has to be done with all library stuff. Another option
would be to place a statically linked busybox and it's
subprogram links into the chroot

Wolfgang Draxinger

 

[support.intranet]

No, chroot applies to the whole process and once applied it can't
be reverted. Otherwise the whole idea of chroot being a FS jail
would not work.

So you need some programs in your chroot: Then put a directory
usr/bin into the chroot directory and bind the system's /usr/bin
there:

mount --bind /usr/bin $chroot/usr/bin

The same has to be done with all library stuff. Another option
would be to place a statically linked busybox and it's
subprogram links into the chroot

Wolfgang Draxinger

Thanks! I'll try the bind way

 

[Remy Blank]

That might not be the best idea... Suddenly the chroot:ed
program has access to the real /usr/bin; and since it likely is
running as root (it was allowed to call chroot()), it can do bad
things to the things in /usr/bin.

If a chrooted process is running as root, it can very easily break out
of the chroot anyway. So...

Also remember, a chroot:ing process should permanently relinquish
its privileges as soon as possible after chroot:ing. There are
way too many fun things a root-running process can do even when
chroot:ed, like creating device files or setuid binaries.

....this is imperative.

All this is of course assuming that the chroot is done for
security reasons.

But here's something that might be interesting:

http://kerneltrap.org/Linux/Abusing_chroot

Short story: chroot is not and never has been a security tool.

-- Remy

 

[Thomas Bellman]

Or symbolic links, of course. Also, wouldn't links prevent
the process from puffing actual binaries in /usr/bin?

Well, if you create symlinks from the chroot jail that try to
point to things outside the chroot, you are at least guaranteed
that you won't give the chroot:ed process to much information.
Unfortunately, you won't be giving it the tools it needs to do
its designed job, either, since symlinks can't escape a chroot.