fakechroot, or any similar tool that uses a facility such as LD_PRELOAD, is not suitable for use in a security context. Such tools are way cool, but can be trivially broken out of by the attacker.

Kapil Paranjape suggests using fakechroot for locking down ssh authorized keys for unison. The idea being unison will run in a (fake)chroot, set up by a regular, non-root user, and will thus be limited to the files you want it to access.

First problem is, any statically linked executable on the system (unison can be used to upload one too) is immune to the fakechroot.

joey@gnu:~>FAKECHROOT_EXCLUDE_PATH=/bin fakeroot fakechroot chroot /tmp/empty /bin/sh
sh-3.2# ls
sh-3.2# ls /
sh-3.2# cd ..
sh-3.2# ls
sh-3.2# sash
Stand-alone shell (version 3.7)
> cd ..
> ls
empty  gconfd-joey  gpg-XhukMB  keyring-ZxSuTB  orbit-joey
> cd ..
> ls
bin    etc         lib     opt   selinux  usr

Getting unison to run a static executable in a setup such as Kapil describes is left as an exercise for the more determined attacker than I.

Here, though, is an easier way.

sh-3.2# ls /
sh-3.2# ls /bin/..
bin    etc         lib     opt   selinux  usr

To understand why this works, notice that I left /bin excluded when I ran fakechroot. (Still .. Is this a bug in fakechroot?)

Or, you could use unison to upload a symlink:

joey@gnu:~>ln -s / /tmp/empty/root
joey@gnu:~>FAKECHROOT_EXCLUDE_PATH=/bin fakeroot fakechroot chroot /tmp/empty /bin/sh
sh-3.2# ls root
bin    etc         lib     opt   selinux  usr

Moral: Taking a program, be it fakechroot or unison, that was never designed with security in mind, and trying to use it as a security barrier, is an open invitation to pain.

comment 1
If you want something that provides similar functionality but is secure (to the best of my knowledge :-) ), you could try Plash.
Comment by mseaborn [myopenid.com]
re: plash

@mseaborn: plash uses a setUID-root tool (in order to make use of chroot) -- http://plash.beasts.org/wiki/ChrootSetuidJail, but the initial setting of the problem was to avoid chroot and other things whose setup would require the rights of root:

The humble chroot is a natural way to implement such restrictions [...]

This is indeed a fine solution ... except, how does one implement it if one is not root on the server machine?

Comment by imz [lj.rossia.org]
How I noticed this discussion
BTW, I came across the discussion here as I was googling a bit in search of existing tools to "jail" a process without being root and evaluating their implementation mechanisms and whether they can be trusted. (The linked page on a Q&A site is supposed to collect answers people have for this question; though, no working simple universal solution has been posted there yet. But it might complement the picture for someone who is looking for a solution for a similar task...)
Comment by imz [lj.rossia.org]