Mast Kalandar

bandar's colander of random jamun aur aam

Thu, 15 Jan 2009

Securing Synchronisation with unison (Mostly Wrong)


Tags: , , , [link] [comments (2)] [raw]

There are a number of documents about how to permit ssh access to run rsync or unison for remote synchronisation by an appropriate configuration of the authorized_keys file. Of these the best two are probably those by Stéphane Kattoor and Christian 'Greek0' Aichinger. Joey Hess also explains some of the pitfalls.

The problem is the familiar one: to limit the file-system hierarchy accessible. The humble chroot is a natural way to implement such restrictions which is probably what led "Greek0" to suggest the use of dchroot.

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

WARNING: The rest of this entry is wrong as was pointed out by Joey Hess. See the update at the bottom.

The package fakechroot by Piotr Roszatycki provides a way out.

The problem I had was as follows:

A recent enough version of fakechroot (version 2.8 worked) allows one to do make use of environment variables as follows:

LD_PRELOAD=libfakechroot.so
LD_LIBRARY_PATH=/usr/lib/fakechroot:/usr/lib64/fakechroot:/usr/lib32/fakechroot:/usr/lib:/lib
FAKECHROOT=true
FAKECHROOT_VERSION=2.8
FAKECHROOT_EXCLUDE_PATH=/bin:/lib:/usr
export LD_LIBRARY_PATH LD_PRELOAD
export FAKECHROOT_EXCLUDE_PATH FAKECHROOT FAKECHROOT_VERSION

After this setup one can run

HOME=/ chroot $HOME/some/dir /usr/bin/unison -server

and the unison server1 will only be able to view /bin, /lib, /usr and $HOME/some/dir; the latter will be mapped to /. (One needs to set the $HOME variable to something sensible for unison to function.)

One should not be tempted to create subdirectories of $HOME/some/dir containing only the "relevant" portions of the system directories for unison. The reason is that those files will be created as me and so could be overwritten by unison.

The creation of a suitable entry in authorized_keys to use this is an easy exercise!

UPDATE: As Joey Hess has noted:

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.

I had thought about the problem of uploading static-linked binaries and had imagined that it had been overcome. However, the basic facts in this case are:


  1. For those trying this out at $HOME with some terminal command like /bin/sh instead of /usr/bin/unison a suggestion is to add /dev to the FAKEROOT_EXCLUDE_PATH variable so that you have access to your terminal. Be aware that giving remote access to /dev may have unintended consequences!


Archives

< January 2009 >
SuMoTuWeThFrSa
     1 2 3
4 5 6 7 8 910
11121314151617
18192021222324
25262728293031

2014, 2013, 2012, 2011, 2010, 2009, 2008, 2007, 2006, 2005, 2004, 2003, 2002, 2001, 2000, 1999, 1997, 1995,