Felix Wolters wrote at about 00:14:37 +0100 on Thursday, February 11, 2021:
> Jeff,
>
> I appreciate your detailled discussion of the topic, and I consider your
> arguments to be strong.
>
> But this …
>
> > Finally, while the sudoer code I shared in my previous note was just
> > aimed at restricting the sudoer power to rsync with specific flags,
> > I'm pretty sure that it could be easily expanded to
> > also limit access to only certain files/directories but just extending
> > the sudoer line to add the paths desired, thereby further restricting
> > the reach of the sudo command allowed.
> seems to be the critical point to me. Have your tried that? (I haven’t
> yet; a quick search at least doesn’t show up manifestations of this
> approach.)
I'm not sure anyone else has done the detailed specific sudoer approach that I
use for backuppc so not surprised it's not documented :)
I'm pretty confident the approach will work to restrict files as you
can verify using 'ps' what the full command line is... Just run 'ps
aux | grep rsync' when you are running a backup...
In fact, my 'sudo' approach worked so well that I was stumped when
backuppc stopped working when I upgraded my rsync version and it
stopped working -- only after much flailing, did I realize that for
rsync >=3.1.x, two new command line parameters ('xC') were added.
Remember ultimately both approaches are trying to do the same thing by
restricting the command lines that can be executed -- but as I laid
out, I think 'normal user escalated with limited sudo' is safer than
'root user restricted by combination of ssh option plus perl plus perl
app of unknown hardness'
I should also point out that there are many subtleties and
vulnerabilities to the command restriction approach that can introduce
security issues. For example, you need to protect against shell
extensions and escapes (as a trivial example, if you allow '&&' then you can
add an arbitrary command) as well as path changes etc.
The sudo people have had years to weed out such vulnerabilities. I
have no idea how well rrsync's developer has tested against all types
of malicious command line manipulations.
>
> > At the end of the day, with rrsync, you are still allowing root
> > access to ssh and that just doesn't feel right.
> Well … any time you administrate a remote machine, you gain root access
> over ssh to it, so this alone is a danger we use to deal with. On the
> other hand, with the rsync-via-sudoers approach – don’t we open rsync to
> the full system, so basically an attacker on the currupted server would
> be able to basically rsync the whole machine to himself? So, at the end
> of the day, aren’t we trading a potential security vulnerability
> (rrsync) with a heavy real one (rsync via sudoers)?
>
>
> Am 10.02.21 um 20:59 schrieb backu...@kosowsky.org:
> > Felix Wolters wrote at about 19:45:49 +0100 on Wednesday, February 10,
> > 2021:
> > > Greg,
> > >
> > > Yupp, that’s the principle, especially refer to the paragraph
> > >
> > https://dev-notes.eu/2016/08/secure-rsync-between-servers/#limit-actions-for-this-ssh-connection-to-restricted-rsync
> > >
> > > I can recommend it so far.
> > >
> > > I may add, that working with a non-privieged user isn’t even necessary
> > > in many cases, as rrsync is able to restrict access to (1.) a specific
> > > command (if need be with specific options), (2.) a specific folder, and
> > > (3.) to read only access – but offer full root access and allowing rsync
> > > -a to keep users, groups and permissions. That makes it powerful.
> >
> > See my earlier note on my concerns about the relative security of this
> > method vs. ssh to a restricted remote user plus a well-constructed
> > sudoer line to elevate only the specific command needed to backup your
> > files/directories.
> >
> > > The problem here just seems to be that rrsync (on the client to back up)
> > > and rsync-bpc are not compatible, and a patched rrsync will – hopefully!
> > > – be the solution.
> >
> >
> > _______________________________________________
> > BackupPC-users mailing list
> > BackupPC-users@lists.sourceforge.net
> > List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
> > Wiki: https://github.com/backuppc/backuppc/wiki
> > Project: https://backuppc.github.io/backuppc/
>
>
> _______________________________________________
> BackupPC-users mailing list
> BackupPC-users@lists.sourceforge.net
> List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
> Wiki: https://github.com/backuppc/backuppc/wiki
> Project: https://backuppc.github.io/backuppc/
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/
