> In fact, my 'sudo' approach worked so well …
Then, how do you restrict access to certain paths in your setups?
Am 11.02.21 um 01:58 schrieb backu...@kosowsky.org:
> 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/
_______________________________________________
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/
