securing rsync backup solutions?
kmk at sanitarium.net
Tue Dec 27 14:02:05 MST 2011
-----BEGIN PGP SIGNED MESSAGE-----
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
> 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
>>> - 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
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
> - 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
> 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/
-----END PGP SIGNATURE-----
More information about the rsync