security of running rsnapshot as root

Given the most recent rsync vulnerability[1] I wonder what the best
practice is to run rsnapshot. I used to run rsnapshot as root on the
backup host, because only then all file modes and ownership are
transferred correctly and no permission problems arise[2]. But that
would make the backup machine vulnerable to any compromised production
servers that are being backed up, right?

So I wonder if people are running rsnapshot as a non-root user in order
to mitigate bugs in rsnapshot/rsync and choose to loose all permission
and ownership info, use tar, or maybe have a better way to handle backups?

[1] https://rsync.samba.org/security.html#s3_1_2
[2] I've learned that the permission problem might be solved by using
rsync --chmod=u+rwX

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss

2016-04-21 20:01 GMT+02:00 Tim Kuijsten <info < at > netsend.nl>:
[quote]Given the most recent rsync vulnerability[1] I wonder what the best
[/quote]
That seems to concern only those running rsyncd.

Best
Martin

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss

Doesn't that vulnerability apply only in case of rsync server (rsyncd)?
That is, not relevant for rsync over ssh or nfs or the like. (I could
be wrong here, haven't looked at it in detail.)

Otherwise, if you're looking for a general solution for possible
bugs in rsync, you could consider running rsnapshot in chrooted
environment or in a docker container or even a fully-blown VM,
and a separate instance for every client.

Of course even that would allow a compromised machine to corrupt its
own old backups in case of a bug like this, but that would be the case
even if rsnapshot ran as a non-root user. I can't offhand think of
any obvious way to protect against that.

For the time being I'm still running rsnapshot as root, considering
the risk low enough.

--
Tapani Tarvainen

On Thu, Apr 21, 2016 at 08:01:47PM +0200, Tim Kuijsten (info < at > netsend.nl) wrote:

[quote]Given the most recent rsync vulnerability[1] I wonder what the best
practice is to run rsnapshot. I used to run rsnapshot as root on the
backup host, because only then all file modes and ownership are
transferred correctly and no permission problems arise[2]. But that
would make the backup machine vulnerable to any compromised production
servers that are being backed up, right?

So I wonder if people are running rsnapshot as a non-root user in order
to mitigate bugs in rsnapshot/rsync and choose to loose all permission
and ownership info, use tar, or maybe have a better way to handle backups?

[1] https://rsync.samba.org/security.html#s3_1_2
[2] I've learned that the permission problem might be solved by using
rsync --chmod=u+rwX
[/quote]
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss

I wonder if a better solution wouldn&#39;t be some sort of chroot.  Normally, my &#39;rsnapshot sync&#39; rsync lines look like:

/usr/bin/rsync -aHSx --delete --numeric-ids --relative --rsh=/usr/bin/ssh rsnapshot < at > i7:/. /.snapshots/.sync/i7/root/

This is for a config with:

snapshot_root   /.snapshots/
backup rsnapshot < at > i7:/./ i7/root/ one_fs=1

Better might be something like:

/usr/bin/rsync -aHSx --delete --numeric-ids --relative --rsh=/usr/bin/ssh --chroot=/.snapshots/.sync/i7/root rsnapshot < at > i7:/. /

Then inappropriate paths could only mess up the host being backed up, which could already happen because it has been compromised.

-scott

On Thu, Apr 21, 2016 at 11:01 AM, Tim Kuijsten <info < at > netsend.nl ([email]info < at > netsend.nl[/email])> wrote:
[quote]Given the most recent rsync vulnerability[1] I wonder what the best
practice is to run rsnapshot. I used to run rsnapshot as root on the
backup host, because only then all file modes and ownership are
transferred correctly and no permission problems arise[2]. But that
would make the backup machine vulnerable to any compromised production
servers that are being backed up, right?

So I wonder if people are running rsnapshot as a non-root user in order
to mitigate bugs in rsnapshot/rsync and choose to loose all permission
and ownership info, use tar, or maybe have a better way to handle backups?

[1] [url=https://rsync.samba.org/security.html#s3_1_2]https://rsync.samba.org/security.html#s3_1_2[/url]
[2] I&#39;ve learned that the permission problem might be solved by using
rsync --chmod=u+rwX

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
[url=https://ad.doubleclick.net/ddm/clk/302982198;130105516;z]https://ad.doubleclick.net/ddm/clk/302982198;130105516;z[/url]
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net ([email]rsnapshot-discuss < at > lists.sourceforge.net[/email])
[url=https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss]https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss[/url]
[/quote]

On Thu, Apr 21, 2016 at 5:15 PM, Scott Hess <scott < at > doubleu.com> wrote:
[quote]I wonder if a better solution wouldn't be some sort of chroot. Normally, my
'rsnapshot sync' rsync lines look like:
[/quote]
Useless if you need files that are not within the chroot cage, such as
system /etc/ files. Useful if you're pulling content form a well
defined rsync chroot cage.

I publish tools for the "rssh" toolkit to do a better job of setting
up rssy style chroot cages for rsync, SFTP, SCP, and SSH if needed.
They're at:

https://github.com/nkadel/rssh-chroot-tools

Others of us are cautious to wrap incoming root enabled rsync
connections with the old "validate-rsync.sh" script, with it tweaked
to allow only read access.

[quote]/usr/bin/rsync -aHSx --delete --numeric-ids --relative --rsh=/usr/bin/ssh
rsnapshot < at > i7:/. /.snapshots/.sync/i7/root/

This is for a config with:

snapshot_root /.snapshots/
backup rsnapshot < at > i7:/./ i7/root/ one_fs=1

Better might be something like:

/usr/bin/rsync -aHSx --delete --numeric-ids --relative --rsh=/usr/bin/ssh
--chroot=/.snapshots/.sync/i7/root rsnapshot < at > i7:/. /

Then inappropriate paths could only mess up the host being backed up, which
could already happen because it has been compromised.

-scott
[/quote]
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss

On Thu, Apr 21, 2016 at 9:28 PM, Nico Kadel-Garcia <nkadel < at > gmail.com ([email]nkadel < at > gmail.com[/email])> wrote:
[quote]On Thu, Apr 21, 2016 at 5:15 PM, Scott Hess <scott < at > doubleu.com ([email]scott < at > doubleu.com[/email])> wrote:
[quote]I wonder if a better solution wouldn&#39;t be some sort of chroot.  Normally, my
&#39;rsnapshot sync&#39; rsync lines look like:
[/quote]
Useless if you need files that are not within the chroot cage, such as
system /etc/ files. Useful if you&#39;re pulling content form a well
defined rsync chroot cage.
[/quote]

I think you may have mis-understood me.  I meant that it might be useful to have the pulling end of rsync (on the rsnapshot server) chroot around the backup directory, since in no case should it be writing outside of that directory.  Of course, it wouldn&#39;t work well without --numeric-ids, and perhaps you&#39;d need other modifications to have it calculate some things before going into the chroot.

[quote] I publish tools for the "rssh" toolkit to do a better job of setting
up rssy style chroot cages for rsync, SFTP, SCP, and SSH if needed.
They&#39;re at:

               [url=https://github.com/nkadel/rssh-chroot-tools]https://github.com/nkadel/rssh-chroot-tools[/url]

Others of us are cautious to wrap incoming root enabled rsync
connections with the old "validate-rsync.sh" script, with it tweaked
to allow only read access.[/quote]

I use that setup also (I mean alternate login with command validation before sudo&#39;ing the real rsync).  It addresses whether the client being backed up fully trusts the server requesting the backup, effectively restricting the server to read access with root permissions (which a compromised server mostly already has due to the backup).  But it doesn&#39;t protect the server from a compromised client attempting an attack.  And it would be kind of cool to extend the untrust on that side to use some sort of sandboxing to actually prevent rsync from doing inappropriate stuff as root, rather than preventing the remote server from asking rsync to do inappropriate stuff.

-scott

On Fri, Apr 22, 2016 at 7:18 AM, Tim Kuijsten <info < at > netsend.nl> wrote:
[quote]Op 22-04-16 om 08:24 schreef Scott Hess:
[quote]
I think you may have mis-understood me. I meant that it might be useful
to have the pulling end of rsync (on the rsnapshot server) chroot around
the backup directory, since in no case should it be writing outside of
that directory. Of course, it wouldn't work well without --numeric-ids,
and perhaps you'd need other modifications to have it calculate some
things before going into the chroot.
[/quote]

Exactly, I've been thinking about something along the lines of pledge [1].
Restrict the rsnapshot/rsync process to one directory on the backup server
per client that is being backed up.
[/quote]
Ahh. Hmm. Yeah, OK, I see your points. I'd bet that you could start
from the tools I mentioned for building rssh chroot cages to build
precisely this, since they support rsync. Alternatively, at least with
RHEL based systems, you could use the "mock" tool for building RPM's
just once to create a chroot cage with the necessary rsynd and perl
components, equipped with a valid /etc/resolv.conf, and use *that* for
your chroot cage on the rsnapsshot server..

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss

Op 22-04-16 om 08:24 schreef Scott Hess:
[quote]I think you may have mis-understood me. I meant that it might be useful
to have the pulling end of rsync (on the rsnapshot server) chroot around
the backup directory, since in no case should it be writing outside of
that directory. Of course, it wouldn't work well without --numeric-ids,
and perhaps you'd need other modifications to have it calculate some
things before going into the chroot.
[/quote]
Exactly, I've been thinking about something along the lines of pledge
[1]. Restrict the rsnapshot/rsync process to one directory on the backup
server per client that is being backed up.

To make the threat model clear. Imagine three servers A, B and C.

A is the rsnapshot server that is taking backups, no incoming
connections, initiates all connections to the servers being backed up
over ssh with rsync.
B is a web server that is being backed up (a client of A)
C is a database server that needs to be backed up (client of A)

The threat model we're talking about is what if either B or C are
compromised and are exploiting the incoming connections of A. This way B
or C might get access to all the backups on A (aside from the fact that
the last vulnerability in rsync might not be a good example as others
have pointed out).

I guess ideally A logs into B and C with different user accounts on A.
Possibly restricted with chroot or pledge, but not really necessary if
using proper permissions and different accounts. The best way to set
this up with the current version of rsnapshot is using different
rsnapshot.conf config files I assume. Please correct me if I'm wrong, I
haven't tried it yet.

[quote]On Thu, Apr 21, 2016 at 9:28 PM, Nico Kadel-Garcia <nkadel < at > gmail.com
<mailto:nkadel < at > gmail.com>> wrote:
[/quote]...
[quote]Others of us are cautious to wrap incoming root enabled rsync
connections with the old "validate-rsync.sh" script, with it tweaked
to allow only read access.
[/quote]
I'm using rrsync from the rsync package for that.
http://packages.ubuntu.com/search?suite=wily&arch=any&mode=filename&searchon=contents&keywords=rrsync

[1] http://man.openbsd.org/OpenBSD-current/man2/pledge.2 Once the path
whitelist feature is available again.

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss

On Thu, Apr 21, 2016 at 02:15:43PM -0700, Scott Hess wrote:

[quote]I wonder if a better solution wouldn't be some sort of chroot ...

/usr/bin/rsync -aHSx --delete --numeric-ids --relative --rsh=/usr/bin/ssh
--chroot=/.snapshots/.sync/i7/root rsnapshot < at > i7:/. /
[/quote]
Is --chroot new in rsync 3?

--
David Cantrell | Official London Perl Mongers Bad Influence

"The whole aim of practical politics is to keep the populace alarmed
(and hence clamorous to be led to safety) by menacing it with an
endless series of hobgoblins, all of them imaginary" -- H. L. Mencken

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss

--chroot is hypothetical syntax on my part. On Apr 25, 2016 4:11 AM, "David Cantrell" <david < at > cantrell.org.uk ([email]david < at > cantrell.org.uk[/email])> wrote:[quote]On Thu, Apr 21, 2016 at 02:15:43PM -0700, Scott Hess wrote:

[quote]I wonder if a better solution wouldn&#39;t be some sort of chroot ...

/usr/bin/rsync -aHSx --delete --numeric-ids --relative --rsh=/usr/bin/ssh
--chroot=/.snapshots/.sync/i7/root rsnapshot < at > i7:/. /
[/quote]
Is --chroot new in rsync 3?

--
David Cantrell | Official London Perl Mongers Bad Influence

"The whole aim of practical politics is to keep the populace alarmed
 (and hence clamorous to be led to safety) by menacing it with an
 endless series of hobgoblins, all of them imaginary"  -- H. L. Mencken

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
[url=https://ad.doubleclick.net/ddm/clk/302982198;130105516;z]https://ad.doubleclick.net/ddm/clk/302982198;130105516;z[/url]
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net ([email]rsnapshot-discuss < at > lists.sourceforge.net[/email])
[url=https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss]https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss[/url]
[/quote]