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.