securing rsync backup solutions?

[Kevin Korb]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/27/11 15:47, Daniel Pocock wrote:
> 
> 
> On 27/12/11 19:54, Kevin Korb wrote:
> 
>> On 12/27/11 13:26, Daniel Pocock wrote:
> 
> 
>>> For full system backup, rsync obviously needs to run as root
>>> on the machine being backed up
> 
>>> For preservation of user/group/permissions info, rsync also 
>>> typically needs to be run as root on the machine storing the
>>> backup - although there appear to be various ways to avoid this
>>> (e.g. using fakeroot -s, or running rsync inside a Xen VM which
>>> only stores the backup of one host)
> 
>>> Can anyone comment on some of the following:
> 
>>> - is it more secure to run rsync as a command within ssh
>>> (probably using command=some_wrapper in authorized_keys) or to
>>> run an rsync daemon (with VPN and/or restricted port
>>> forwarding, e.g. permitopen="localhost:873" in authorized_keys)
>>> ?
> 
>> I prefer ssh both for encryption and superior authentication
>> (key authentication).  It is easy to configure sshd to only allow
>> root to login using an ssh key and you can restrict where that
>> key can be used and what it can do.
> 
>> I would actually go as far as to say forget rsyncd for system
>> backups. That just isn't what it was designed for.  With rsync
>> over ssh you don't even need to bother with the rsyncd.conf
>> file.
> 
> I agree that ssh with key based auth is great, and I already use it
> for a range of purposes, for example, I've deployed a range of
> OpenWRT boxes that `phone home' using ssh and an RSA key.  With
> DynDNS recently cutting their free services, the extra effort I had
> put in developing an ssh-based solution instantly proved it's
> value.
> 
>>> - are there any ideal examples of wrapper scripts that set up
>>> a fakeroot environment (either on each invocation or wrapping
>>> the rsync daemon)?
> 
>> It isn't exactly what you are asking for but check out rrsync in
>> the support directory of the rsync source tree.
> 
> Found it: http://rsync.samba.org/ftp/unpacked/rsync/support/rrsync 
> - this appears good for some of my concerns, and it even exists in
> the Debian package at /usr/share/doc/rsync/scripts/rrsync.gz
> 
> I notice it can restrict the flow of data to go from client to
> server, that is another nice feature that I had in mind
> 
>>> - is there any facility for command line filtering (or any
>>> example of such a wrapper script) when running in ssh mode?
>>> E.g. to stop people using `some nasty rm command` or detect
>>> attempts to steal ../../../secret_file ?
> 
>> Again, see rrsync though it is for rsync over ssh not rsyncd.
> 
> Does rsync provide any way to execute arbitrary server-side code
> when used in this manner, e.g. by putting backticks on the command
> line?  I think I remember seeing such an example on the web
> somewhere, and I'm not sure if rrsync is able to detect that

When you use rsync over ssh you can provide an arbitrary --rsync-path
which can include just about anything.  For instance I have used
- --rsync-path '/usr/bin/ionice -c3 /usr/bin/rsync'  Since rrsync is a
forced command that would be completely ignored.

> 
>>> - as an alternative to fakeroot, is there any type of
>>> filesystem that can be run on the backup server that would
>>> allow non-root processes to manipulate file ownership and
>>> permissions?  I couldn't find examples of this in the common
>>> Linux filesystems.
> 
>> I am not aware of one and I think most people would consider it
>> to be a security violation.
> 
> 
> To be more precise: the uid of the rsync process would not be able
> to access/modify files owned by root on all filesystems of the
> backup server.  It would only presumably have such access on a
> dedicated filesystem for storing the backup.
> 

The only way I know to restrict root in that way is with rrsync,
scponly, rssh, or similar restrictions.  Even a chroot isn't going to
do it since root can easily escape from a chroot.

>>> - is there any possibility for the rsync process on the backup 
>>> server to keep the destination files within a tar file (or
>>> some virtual filesystem that is backed by a tar file) and then
>>> the owner/permission data can be stored in the tar file
>>> (without needing to run as root)?
> 
>> There might be something in Linux's fuse.  There is just about 
>> everything in fuse.
> 
> I came across this: http://www.cybernoia.de/software/archivemount/ 
> and this: http://lwn.net/Articles/131856/
> 
> so it does appear Fuse may allow rsync to make arbitrary file 
> owner/permission changes, and the rsync process would only need to
> run as a user with sufficient permissions to read/write the tar
> file

That is a neat idea.  If it ends up working for you I would like to
hear about it.

> 
> I'd be particularly interested to know if anyone has tried this
> and confirmed it to be robust (or confirmed the opposite)?
> 
> Obviously, you wouldn't want to be able to run setuid binaries
> stored on such an FS
> 
> 
>>> I've seen a few examples online that answer parts of these 
>>> questions, but nobody has shared a complete recipe, and some of
>>> the issues are not addressed anywhere
> 
>> The first question is do you want to pull or push your backups.
>> That changes things big time.  Since you are talking about using
>> fakeroot (I assume you mean --fake-super) I assume you are
>> planning to push your backups from the client to the backup
>> server.  This does have the advantage of only needing root on
>> client side.  OTOH, it could allow an attacker who gains control
>> of your client to infect or destroy your backups of a system.
> 
> I was thinking about using either approach - the fakeroot utility
> from Debian, or the --fake-super argument.
> 
> As for the direction (push or pull), I am looking to set up a
> number of rsyncs:
> 
> - server-to-server: these should be run by cron (so the ssh keys
> may be kept without encryption, or unlocked manually at boot) -
> these may be either push or pull, but my current testing has been
> pull
> 
> - laptop-to-server: the laptop tends to roam a lot, network
> conditions vary from place to place, and the rsync will be
> initiated manually, so it is likely to be a `push' operation, the
> ssh keys will definitely need to be encrypted and unlocked
> manually, but even with that security, I want to ensure the keys
> have the minimum level of access possible on the server - the
> laptop definitely shouldn't have a key for the root account

I only deal with my own laptop so I just do my standard pull based
backups on it whenever I feel like it.  To support other people's
laptops I would probably try to engineer something that allows the
laptop user to tell the backup server to pull a backup.  That way the
same security model is being used in either mode instead of having to
deal with two of them.

>> I prefer to pull my backups.  This means that I run as root on
>> both ends but it also means that I can make an ultra secure
>> backup server that has no other services running.  It can ssh as
>> root to any other system by key but that key will only work from
>> its IP address.  I could make it so that key can only run rsync
>> (or rrsync) but I don't because I also use it to gather non-file
>> information such as partition tables and to activate LVM2
>> snapshots.
> 
> I agree that has some desirable characteristics
> 
> Just out of interest, why not have separate accounts for each of
> those activities, with each account having the minimum level of
> access necessary?  E.g. you could have a normal user with sudo
> access to the lvm commands?

I haven't felt it necessary.  Also, I tend to not use sudo in that
way.  In fact I tend to not even have it installed.  Also, I have
always thought of backups as a filesystem level operation so I always
backup with rsync --one-file-system and do separate rsyncs for each
filesystem.  That would make even more keys with rrsync forced.  I am
just not that paranoid and I keep my keys to myself ;)

- -- 
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
	Kevin Korb			Phone:    (407) 252-6853
	Systems Administrator		Internet:
	FutureQuest, Inc.		Kevin at FutureQuest.net  (work)
	Orlando, Florida		kmk at sanitarium.net (personal)
	Web page:			http://www.sanitarium.net/
	PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk76Mk0ACgkQVKC1jlbQAQeufACgm+Ecg8uw6zSRZZ6Qv3JpPwtF
OSQAoK4Ho1lU3stXjQVKUiUccItmWh3c
=LyCv
-----END PGP SIGNATURE-----