Thu, 15 Jan 2009

Securing Synchronisation with unison (Mostly Wrong)

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?

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 asme 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:

unison -server does not have an
option to limit its view of the directory heirarchy. The
upstream authors are aware of this but it is not clear whether
they perceive it as a bug.

fakechroot is meant to give a different view
of the directory heirarchy to programs that use standard
libc calls. It does not block access to
part of the tree as the real chroot does; again, this is not
necessarily a bug.

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! ↩