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

[Chris Green via rsync]

Greg Minshall via rsync  wrote:
> >If you only do backups at 1am (or whenever), why would your
> > backup machine enable ssh outside of the range 12:59 - 01:01?
> 
> Greg's rule of windows: the narrower the window, the more likely it will
> be hit.  :)
> 
But I use Linux, not windows..  :-)

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

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

[L A Walsh via rsync]

On 2021/08/07 08:45, Chris Green via rsync wrote:




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!


  


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.
  


   Yeah, that's why I had the 'previous versions thing working.
I hope to get that working again at some point a bit more efficiently.

I know I need the protection against myself too!


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.
  


   Get a few small computers like your pi, and duplicate them.  swap a new
one in if there's a problem.  Or boot from a DVD -- installs everything
on boot, and then download variable info from your backup server using
knock-knock...*


  

 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! :-)
  

you too eh, what power we have! ;-)


A pretty cool way to get your laptop "let in" to the backup server.

Have a random sequence of port open attemps Choose a capital port, a 
small..oh

wait, that's letters...anyway, have a prog that detects the probes.
If it gets the right sequence of 10, 20, 60 probes, (whatever), then
it opens up the ssh->backup port for 5 minutes or until your laptop
connects, (whichever is shorter).  If you didn't get in within 5 minutes,
prolly need a faster computer.  Be sure to make your OPIE check a range of
of unused passwords in case you get out of sync.



Have the probe-pattern be a 1-time use pattern and generate a few hundred
of them for each computer in advance.  now you have One-time use passwords
just to turn on your secure backup.  If someone breaks that, close up 
shop and

move to baja calif and retire! 



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

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

[Greg Minshall via rsync]

>If you only do backups at 1am (or whenever), why would your
> backup machine enable ssh outside of the range 12:59 - 01:01?

Greg's rule of windows: the narrower the window, the more likely it will
be hit.  :)

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

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

[Bri Hatch via rsync]

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

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 
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  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.
> >

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

[Chris Green via rsync]

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

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

[raf via rsync]

On Sat, Aug 07, 2021 at 11:44:34AM +0100, Chris Green via rsync 
 wrote:

> L A Walsh via rsync  wrote:
> > On 2021/08/03 07:09, Chris Green via rsync wrote:
> > > I already have an rsync daemon server running elsewhere, I can add
> > > this requirement to that I think.  Thank you.
> > >   
> > 
> > 
> > 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 (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.
> 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.

You can use my sshdo program (https://github.com/raforg/sshdo)
to solve this problem. It limits the commands that a
key is allowed to execute to just those commands that
it has been trained on and nothing else. It makes it OK
to have an unencrypted ssh key used for automated or
scripted actions such as backups. The key can only be
used to execute the exact commands that you need it to.

It works by allowing everything during a brief learning
period, and then you tell it to add the commands that
have been encountered to its policy and disallow
anything else. You can also periodically unlearn or
relearn as needed. It does all the heavy lifting. You
just have to examine what it's seeing, and decide if it
should be added to the policy.

> The backup system that runs the rsync daemon has its rsync configured
> with 'refuse options = delete' 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.
> 
> -- 
> Chris Green

cheers,
raf


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

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

[L A Walsh via rsync]

On 2021/08/07 03:44, Chris Green via rsync wrote:

L A Walsh via rsync  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?



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. 


   My desktop computer essentially has root access FROM the windows
desktop (my normal user is a domain admin, and can alter permissions
or make changes to any file on my server.  In my case I regard my desktop+
server as a "split system", with the Winbox being my desktop, and the
Linbox being the "backend" of my computer.  The Winbox doesn't normally
have direct access to the network and all of my "content" files /docs/ progs
residing on my linbox.  The Linbox handles backups, network access,
a proxy for the winbox, incoming+outgoing email (dovecot+sendmail), etc.
The linbox does daily security scans and computer maintenance tasks that
I don't trust to letting Windows do it as the linbox provide better 
feedback.


Additionally my linbox has has direct access to any file on my desktop
as well, thought indirectly in that my linbox acts as a samba domain server
for the desktop (thus providing single-signon for my home machines based
on the linbox).  Its slightly moot, in my case to worry about someone on
my desktop being able to access content on my linbox, since all of the
"content" files (docs dir, music, video -- all personal files on desktop)
actually reside on my server where they are backed up daily via xfs_backup.
They are connected via a dedicated, direct 10Gb ethernet that gives 
200-400MB/s(M=2**20 bytes) nominal speed up to 600MB.

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).

   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.


 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.

For example.  My home partition:
home-210501-0-0438.dump  home-210512-1-0431.dump  home-210523-1-0430.dump
home-210601-0-0437.dump  home-210603-2-0431.dump  home-210612-1-0433.dump
...
home-210729-6-0430.dump  home-210730-9-0430.dump  home-210731-8-0430.dump
home-210801-0-0438.dump  home-210803-2-0430.dump  home-210804-5-0430.dump
home-210805-4-0430.dump  home-210806-7-0430.dump  home-210807-6-0430.dump

Can be restored to any of the dates with a script:

 Display_Only=1 full_restore home restore 210716

restore home-210701-0-0442.dump to /home/cache/restore
restore home-210712-1-0430.dump to /home/cache/restore
restore home-210714-2-0430.dump to /home/cache/restore
restore home-210716-4-0430.dump to /home/cache/restore


For several months I provided a few back-weeks of
'Restore previous versions' that did checkpoints 4x/day.

Constructed it using rsync, but it really was too much work for
too little feature.


Anyway, I'm aware of various security considerations and it seems like
the best single thing would be a fast-timout screen saver that
would require a password to stop (in addition to the
root-ssh login)... 


Hope this is at least a little helpful, sorry for not 

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

[Chris Green via rsync]

L A Walsh via rsync  wrote:
> On 2021/08/03 07:09, Chris Green via rsync wrote:
> > I already have an rsync daemon server running elsewhere, I can add
> > this requirement to that I think.  Thank you.
> >   
> 
> 
> 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 (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.

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.


The backup system that runs the rsync daemon has its rsync configured
with 'refuse options = delete' 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.

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

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

[L A Walsh via rsync]

On 2021/08/03 07:09, Chris Green via rsync wrote:

I already have an rsync daemon server running elsewhere, I can add
this requirement to that I think.  Thank you.
  



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.

Then "export RSYNC_RSH=ssh" on your source before running
rsync (as root).

I don't use an rsyncd on the remote.  Try it in some sub-dir first.
Don't cross fs boundaries, so like I use flags (for xfs->xfs) like:

rsync -auvxHAXOW --del /usr/local/fonts/  remotesys:/usr/local/fonts/

pathnames are finicky.  While
 this pair works:
aa/dir/ (->) bb/dir/
 and I think this one does:
aa/dir bb/

  there are more that aren't reliable but may work occasionally
(like work 1st time, but not 2nd...). Some examples:

aa/dir/ bb/dir
aa/dir/. bb/dir/.
aa/dir bb
aa/dir/ bb/


then do your rsync as normal run rsync as root to the remote as normal.

Passwordless ssh logins are used where remote root and
remote-passworded logins are forbidden, since with a strong
key, there is no password to crack.  Since you may not want
remote login directly to root, you might prohibit use of passwords
for root (forcing use of a secure key).

There can be many caveats,  so try on smaller, backed up fs's first...
If you have room, transfer to a tmpdir then move into place.

Good luck...




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

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

[Chris Green via rsync]

Andy Smith via rsync  wrote:
> 
> > I've set it up so chris can run rsync with root permissions.
> > However I'm not quite sure how to get it to work as one needs to say
> > "sudo rsync" to get the root privilege.  How do you do that?
> 
> The first link I sent you had an example of that: --rsync-path="sudo
> rsync"
> 
Ah, oops, I'm sure I looked for that in the man page! :-)  I thought
it should be possible but couldn't find it.  Thanks.

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

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

[Andy Smith via rsync]

Hello,

On Tue, Aug 03, 2021 at 03:05:27PM +0100, Chris Green via rsync wrote:
> Remember, as I said, this is all Debianland with no real root login,
> while I could add one I'd prefer not to.  

Your system already has a root user and if you added an SSH public
key to its authorized_keys file (and allowed root login by public
key only in sshd_config) then SSH login would work. The only form of
login you would have added is "by this specific ssh key". The
account could still remain password locked as it is now.

It is difficult for me to see why such a setup would be inherently
more secure than one where a regular user account can do absolutely
anything (i.e. run rsync as root without password prompt),
especially given that a regular user account is likely to run a lot
of other software some of which may have bugs.

But we all choose our security stance.

> I've set it up so chris can run rsync with root permissions.
> However I'm not quite sure how to get it to work as one needs to say
> "sudo rsync" to get the root privilege.  How do you do that?

The first link I sent you had an example of that: --rsync-path="sudo
rsync"

Cheers,
Andy

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

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

[raf via rsync]

On Tue, Aug 03, 2021 at 10:51:34AM +, Andy Smith via rsync 
 wrote:

> Hi Chris,
> 
> On Tue, Aug 03, 2021 at 09:48:37AM +0100, Chris Green via rsync wrote:
> > But how do you handle the other end to restore the root ownership etc.?
> > The script has to do something like:-
> > 
> > rsync -a /etc/ chris@remote:backups/etc/
> > 
> > So at the remote end it only has chris' privileges.
> 
> A couple of options:
> 
> 
> https://strugglers.net/~andy/blog/2021/04/10/rsync-and-sudo-without-x-forwarding/
> 
> Since you want to automate it I'd go with letting root log in by ssh
> key only, and force the key to work only with a specific script.
> 
> Here is an example forced command that only allows rsync
> 
> https://www.guyrutenberg.com/2014/01/14/restricting-ssh-access-to-rsync/
> 
> This is still vulnerable to doing anything that rsync can do. You
> can secure it further by making a script that only does the specific
> things you need rsync to do, e.g. the exact parameters and paths,
> and force that script instead.
> 
> Cheers,
> Andy

An easy way to restrict rsync (or anything else that
operates over ssh) to only the precise commands you
need it to do, without allowing it free reign, is my
sshdo program (https://github.com/raforg/sshdo). You
can use it to learn what rsync is doing, then lock it
down to only what it has seen happen and nothing else.
That might help.

cheers,
raf


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

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

[Chris Green via rsync]

Andy Smith via rsync  wrote:
> Hi Chris,
> 
> On Tue, Aug 03, 2021 at 11:48:31AM +0100, Chris Green via rsync wrote:
> > If I used the --super option (in a command like the one above) and
> > chris can run rsync as root on the remote end (via options in the
> > sudoers file) will this do what I want?  I guess I can go away and try
> > it! :-)
> 
> You don't need --super if the remote side actually is running as
> root (either because you logged in as "root" or you logged in as
> "chris" but told it to execute "sudo rsync").
> 
Remember, as I said, this is all Debianland with no real root login,
while I could add one I'd prefer not to.  


> If you're going to use sudo then you'll want to set it NOPASSWD so
> it doesn't ask for a sudo password. Possibly restricting that only
> to uses of rsync or a specific script, otherwise it is giving
> "chris" blanket sudo access without a password.
> 
Yes, I've set it up so chris can run rsync with root permissions.
However I'm not quite sure how to get it to work as one needs to say
"sudo rsync" to get the root privilege.  How do you do that?

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

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

[Chris Green via rsync]

Paul Slootman via rsync  wrote:
> On Tue 03 Aug 2021, Chris Green via rsync wrote:
> 
> > Is there a way to copy (for example) the /etc hierarchy from one
> > system to another preserving root ownership of files and without
> > revealing root passwords all over the place?
> 
> Best way is to run an rsync daemon on the source system, and be sure to
> use "uid = 0" so that the daemon reads the source as root.
> 
> > So, it's easy for the sending end to be run as root as it's going to be
> > run by a script in /etc/cron.daily, so it can access all the files in
> > /etc even if only readable by root.
> 
> Hmm I prefer to use "pull" mechanisms as that's more secure (harder to
> screw up the destination).
> 
> So create a /etc/rsyncd.conf file with the appropriate config, something
> like:
> 
> [etc]
>   path = /etc
>   read only = yes
>   hosts allow = another-system
>   uid = 0
> 
> If using systemd then enable and start the daemon:
> 
> systemctl enable rsync.service
> systemctl start rsync.service
> 
> Then on another-system as root run rsync:
> 
> rsync -a one-system::etc/ /backups/etc/
> 
> I usually also use -H for hard links, but /etc usually won't have those.
> 
> You can also use an rsync password to make this a bit more secure so
> that not everyone on another-system can read all of /etc from
> one-system. Details in the manpage.
> 
I already have an rsync daemon server running elsewhere, I can add
this requirement to that I think.  Thank you.

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

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

[Chris Green via rsync]

Andy Smith via rsync  wrote:
> Hi Chris,
> 
> On Tue, Aug 03, 2021 at 09:48:37AM +0100, Chris Green via rsync wrote:
> > But how do you handle the other end to restore the root ownership etc.?
> > The script has to do something like:-
> > 
> > rsync -a /etc/ chris@remote:backups/etc/
> > 
> > So at the remote end it only has chris' privileges.
> 
> A couple of options:
> 
> 
> https://strugglers.net/~andy/blog/2021/04/10/rsync-and-sudo-without-x-forwarding/
> 
> Since you want to automate it I'd go with letting root log in by ssh
> key only, and force the key to work only with a specific script.
> 
> Here is an example forced command that only allows rsync
> 
> https://www.guyrutenberg.com/2014/01/14/restricting-ssh-access-to-rsync/
> 
> This is still vulnerable to doing anything that rsync can do. You
> can secure it further by making a script that only does the specific
> things you need rsync to do, e.g. the exact parameters and paths,
> and force that script instead.
> 
Ah yes, I've done this elsewhere using 'rrsync' at the receiving end,
it's another possible approach to investigate, thanks.

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

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

[Paul Slootman via rsync]

On Tue 03 Aug 2021, Chris Green via rsync wrote:

> Is there a way to copy (for example) the /etc hierarchy from one
> system to another preserving root ownership of files and without
> revealing root passwords all over the place?

Best way is to run an rsync daemon on the source system, and be sure to
use "uid = 0" so that the daemon reads the source as root.

> So, it's easy for the sending end to be run as root as it's going to be
> run by a script in /etc/cron.daily, so it can access all the files in
> /etc even if only readable by root.

Hmm I prefer to use "pull" mechanisms as that's more secure (harder to
screw up the destination).

So create a /etc/rsyncd.conf file with the appropriate config, something
like:

[etc]
  path = /etc
  read only = yes
  hosts allow = another-system
  uid = 0

If using systemd then enable and start the daemon:

systemctl enable rsync.service
systemctl start rsync.service

Then on another-system as root run rsync:

rsync -a one-system::etc/ /backups/etc/

I usually also use -H for hard links, but /etc usually won't have those.

You can also use an rsync password to make this a bit more secure so
that not everyone on another-system can read all of /etc from
one-system. Details in the manpage.


Paul

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

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

[Andy Smith via rsync]

Hi Chris,

On Tue, Aug 03, 2021 at 11:48:31AM +0100, Chris Green via rsync wrote:
> If I used the --super option (in a command like the one above) and
> chris can run rsync as root on the remote end (via options in the
> sudoers file) will this do what I want?  I guess I can go away and try
> it! :-)

You don't need --super if the remote side actually is running as
root (either because you logged in as "root" or you logged in as
"chris" but told it to execute "sudo rsync").

If you're going to use sudo then you'll want to set it NOPASSWD so
it doesn't ask for a sudo password. Possibly restricting that only
to uses of rsync or a specific script, otherwise it is giving
"chris" blanket sudo access without a password.

Cheers,
Andy

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

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

[Andy Smith via rsync]

Hi Chris,

On Tue, Aug 03, 2021 at 09:48:37AM +0100, Chris Green via rsync wrote:
> But how do you handle the other end to restore the root ownership etc.?
> The script has to do something like:-
> 
> rsync -a /etc/ chris@remote:backups/etc/
> 
> So at the remote end it only has chris' privileges.

A couple of options:


https://strugglers.net/~andy/blog/2021/04/10/rsync-and-sudo-without-x-forwarding/

Since you want to automate it I'd go with letting root log in by ssh
key only, and force the key to work only with a specific script.

Here is an example forced command that only allows rsync

https://www.guyrutenberg.com/2014/01/14/restricting-ssh-access-to-rsync/

This is still vulnerable to doing anything that rsync can do. You
can secure it further by making a script that only does the specific
things you need rsync to do, e.g. the exact parameters and paths,
and force that script instead.

Cheers,
Andy

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

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

[Chris Green via rsync]

Chris Green via rsync  wrote:
> Is there a way to copy (for example) the /etc hierarchy from one
> system to another preserving root ownership of files and without
> revealing root passwords all over the place?
> 
> This is actually from and to Debian based systems (from Raspberry Pi
> to Xubuntu) so there's no actual root user login anyway, it's all sudo
> from privileged user.
> 
> So, it's easy for the sending end to be run as root as it's going to be
> run by a script in /etc/cron.daily, so it can access all the files in
> /etc even if only readable by root.
> 
> But how do you handle the other end to restore the root ownership etc.?
> The script has to do something like:-
> 
> rsync -a /etc/ chris@remote:backups/etc/
> 
> So at the remote end it only has chris' privileges.
> 
> 
> I want to automate this, I don't want any manual intervention to be
> needed.
> 

If I used the --super option (in a command like the one above) and
chris can run rsync as root on the remote end (via options in the
sudoers file) will this do what I want?  I guess I can go away and try
it! :-)

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