Mast Kalandar

bandar's colander of random jamun aur aam

Thu, 15 Jan 2009

< Password prompts with pinentry under screen | · | Stallman vs Torvalds (Oh! No! Not again!) >

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:

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!

comment bubble Joey Hess, Fri Jan 16 06:20:14 2009 permanent link

Thanks for posting the correction.

So, how to secure unison? The best approach I can think of is writing a script that runs unison in a chroot, and then arranging for that script to run as root. (Via sudo or suid). I guess it would be wise to make the script su back to the normal user after chrooting and before running unison.

Luckily, the few computers I unison between are mostly trusted, as this seems like a pain to setup.

comment bubble Kapil Hari Paranjape, Fri Jan 16 15:55:14 2009 permanent link

The solution described by Christian "Greek0" Aichinger (see link in
the entry) uses dchroot to carry out the steps outlined by Joey in
his comment.

One could hack at the unison code to introduce a "toplevel"
directory in -server mode, but one would still need to take care of
other issues like link traversal. As Joey has said, unison is not
written with this use-case in mind.

E-mail (will not be displayed)
OpenID (required)
Simple HTML and wiki markup are allowed.


< January 2009 >
     1 2 3
4 5 6 7 8 910

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