How to manage root<-->root rsync keeping permissions?

Bri Hatch bri at ifokr.org
Sat Aug 7 16:22:39 UTC 2021


The original request was to be able to copy files from local /etc to a
remote /etc
while retaining file permissions (perms, owner, etc). This does require
root on
the receiving box in some way.

Commenting on some previous suggestions:

* connecting to the remote system as a non-root user and giving it
unrestricted
  'sudo rsync', which is invoked via --rsync-path='sudo rsync'. This can
work
  only if you give sudo for only the exact specific rsync command that is
  generated on the server. If you simply allow 'sudo rsync' then an attacker
  on the client machine could trick it into running dangerous arguments.

* --super option: this makes rsync attempt to perform actions it doesn't
think it
  can because the system isn't actually root. Unless you're doing some
additional
  magic to provide the receiving user to be able to 'chown/etc' files it
should
  not be able to (think kernel capabilities) then this won't work.


I do think the cleanest way would be to enable root ssh in
/etc/ssh/sshd_config
and set up ssh key-based trust and restrict that key to an rsync wrapper
that
validates the command.

The rrsync and sshdo wrappers are already described in this thread.

A third option is authprogs. It differs from the other options slightly:

rrsync: it can restrict download vs upload and directory, but no better
granularity.

sshdo: learns commands but doesn't "understand them", so that's on you from
both
a security and management standpoint. Main drawback in the rsync world is
that when
rsync client starts sending equivalent(ish) but different looking server
arguments you
will need to have it green light the new ones. For example 'rsync -v -v'
and 'rsync -vv'
are equivalent, but look different enough that sshdo won't catch it.


Authprogs works differently in that it parses and groks the rsync command
line options,
and rather than approving a specific command line you define the features
you want to
allow or deny, and you configure your rules via a yaml file. It also offers
the ability to restrict
commands based on other indicators such as key name and source IP.

Man page at https://github.com/daethnir/authprogs/blob/main/doc/authprogs.md
and specifically
jump to the rsync-subrules
<https://github.com/daethnir/authprogs/blob/main/doc/authprogs.md#rsync-subrules>
section.


An example config for you:

    # Allow rsync to recursively sync /etc/ to the server
    # in archive mode (-a, or any subset of -logptrD)
    # but do not allow download
    -
      from: [192.168.98.76, 192.168.54.32]
      allow:
        - rule_type: rsync
          allow_upload: true
          allow_recursive: true
          allow_archive: true
          paths:
            - /etc

Like sshdo you can use the same ssh key for multiple rsync commands which
makes management
easier.

authprogs actually can run on the server and configure your ssh
authorized_keys file for you

    authprogs --install_key id_rsa.pub

and it defaults to disabling a bunch of awesome but potentially dangerous
ssh options like X11 forwarding.


If running via a direct root login is not an option I'd be happy to look at
what changes authprogs
would need, if any, to work via 'sudo'. Both sshdo and authprogs would at a
minimum need to have the
SSH_ORIGINAL_COMMAND environment variable exempted by sudo purging rules or
be able to take these
as additional command line options.


As with any of these ssh-based options, protecting your client machine is
critical because either you
have an ssh key unencrypted on disk (bad idea) or loaded into a local
ssh-agent (still accessible to
any process running as that user or root, but cannot be exfiltrated to
another machine by simply copying
the file, and unavailable at reboot.)




On Sat, Aug 7, 2021 at 9:08 AM Chris Green via rsync <rsync at lists.samba.org>
wrote:

> On Sat, Aug 07, 2021 at 08:10:47AM -0700, L A Walsh wrote:
> > On 2021/08/07 03:44, Chris Green via rsync wrote:
> > > L A Walsh via rsync <rsync at lists.samba.org> wrote:
> > > > It seems to me, a safer bet would be to generate an ssh-cert
> > > > that allows a passwdless login from your sys to the remote.
> > > >
> > > The trouble with that is that it leaves a big security hole.
> > ----
> >
> >    If you only do backups at 1am (or whenever), why would your
> > backup machine enable ssh outside of the range 12:59 - 01:01?
> >
> Because cron/anacron isn't perfect and the machine being backed up nay
> not be turned on all the time so the time that it tries to backup is
> most definitely not fixed accurately!
>
>
> > >
> > > If (for example) I leave my laptop turned on somewhere, or someone
> > > wanders into my study where my desktop machine is they have instant,
> > > passwordless access to the remote backup machine.
> > ----
> >    If your desktop machine is that open to casual wanderers, perhaps
> > you should enable a passwd locked screen saver activating after a few
> > minutes?  I keep my home computer unlocked all the time as well, but I
> > don't have walk-through visitors that might mess with it.
> >
> Neither do I, though we do have family and friends around the place
> quite a lot.  I agree, in general, my desktop machine isn't
> particularly accessible or vulnerable but it *might* get hacked or
> accessed by an intruder and I thus try my best to protect the backup
> machine from it.
>
> > > I try very hard to make my backups secure from attack so that if my
> > > desktop or laptop is compromised somehow the (remote) backups are
> > > still secure.
> > ---
> >    Excellent!  In my case, my laptop/desktop (used to be a laptop) is
> > thoroughly entwined with the server such that one has trouble functioning
> > without the other.
> >
> >    In your case, though, I was thinking of a backup process that would
> > only be used when my laptop was on a secure network (like @ home).
> >
> Yes, but as above, if my laptop is compromised in any way (hopefully
> unlikely but still possible) I want my backups to be safe still.
>
> >    If there is risk to your laptop while @ home, hopefully it has a
> > short-timeout that bounces it to the screen saver that requires a
> > password to unlock?t
> > >
> > > The backup system that runs the rsync daemon has its rsync configured
> > > with 'refuse options = delete'
> > ---
> >    Ahh...I thought you were actually trying to keep them in sync.
> > Maybe you might think about using an actual backup prog like tar.
> > In my case, the Users/groups are the same.  Tar handles ext attrs and
> > acls and can keep track of backing files up that have actually changed
> > rather than relying on time/date stamps.
> >
> My *backups* of important data are incremental backups done once a day
> for every machine. I also do hourly incremental backups on my desktop
> machine but that is more for protecting myself against myself than for
> protecting against intruders or hardware failure.
>
> The original point of this thread is about something closer to
> synchronising my (small, Raspberry Pi) DNS server so that if it fails
> I can get a DNS server back up and running as quickly as possible.
>
>
> > >  so not only does someone with access to
> > > my desktop/laptop need to know the rsyncd username and password but
> > > they also cannot delete my existing backups.  It runs incremental
> > > backups so nothing is ever overwritten either.
> > ----
> >    BTW, incremental backups aren't really the same as 'update' backups,
> > they keep track of the state of the file system (including files no
> longer
> > there)
> > so you can restore your desktop to a specific day before some unwanted
> > updated was introduced and kept by an update-only backup system.
> >
> Yes, exactly, or more to the point (in my case anyway) I can restore a
> specific file to a few hours ago after I've scrambled it in some
> disastrous way! :-)
>
> I use the rsync --link-dest option to make the incremental backups
> (and, yes, I know this means that I only really have one copy of
> unchanging files.  I do have more than one backup)
>
> > Constructed it using rsync, but it really was too much work for
> > too little feature.
> >
> Mine too, as I said, is rsync with 'before the backup' and 'after the
> backup' python scripts that do the housekeeping like thinning out
> backups as they get older.
>
> --
> Chris Green
>
> --
> Please use reply-all for most replies to avoid omitting the mailing list.
> To unsubscribe or change options:
> https://lists.samba.org/mailman/listinfo/rsync
> Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
>


-- 
Bri Hatch, Systems and Security Engineer. http://www.ifokr.org/bri/

The sooner you fall behind, the more time you'll have to catch up.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/rsync/attachments/20210807/41f7a120/attachment.htm>


More information about the rsync mailing list