So there's basically no point in having just "--sender" - it doesn't make anything "more secure"? Even through obscurity? (presumably an attacker running rsync wouldn't know they needed to have --sender as the first param)?
The only person who has access to BackupPC and its web UI is me. The machine it runs on is locked down by IP, only SSH access (web UI is accessed through the tunnel with port forwarding) and a .htaccess password is thrown in for good measure. The "clients" in my case are web application servers rather than end users. Root account access to them is disabled, only certain users can SSH with their key pairs. Kind regards, Jamie ------------------------------ Jamie Burchell Senior Web Developer 01732 449974 ja...@ib3.uk ------------------------------ ib3 Limited 2 Lyons Wharf, Lyons Crescent, Tonbridge TN9 1EX 01732 449970 https://www.ib3.uk/ ------------------------------ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of ib3 Limited. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. ib3 is a limited company registered in England and Wales. Registered number: 3734612. Registered office: Riverside, 2 Lyons Wharf, Lyons Crescent, Tonbridge, Kent TN9 1EX, United Kingdom. -----Original Message----- From: Holger Parplies [mailto:wb...@parplies.de] Sent: 16 November 2017 16:58 To: Jamie Burchell <ja...@ib3.co.uk>; Bzzzz <lazyvi...@gmx.com> Cc: backuppc-users@lists.sourceforge.net Subject: Re: [BackupPC-users] error in rsync protocol data stream (code 12) (Restoring) Bzzzz wrote on 2017-11-16 00:50:52 +0100 [Re: [BackupPC-users] error in rsync protocol data stream (code 12) (Restoring)]: > [...] > In short: being root and (especially) removing directories is bad, on > the other hand, using root as part of a controlled process doesn't > mean that you'll be hacked or whatever - furthermore, doing some > stuffs as root is compulsory for some maintenance work. wrong. Not understanding a concept and giving advice about it is bad. Jamie Burchell wrote on 2017-11-15 22:48:01 -0000 [[BackupPC-users] error in rsync protocol data stream (code 12) (Restoring)]: > [...] > I followed the instructions to make a restricted backuppc user on > client machines with limited sudo permission thus: > > backuppc ALL=NOPASSWD: /usr/bin/rsync --server --sender * > > This works fine for backing up, but I just discovered I can no longer > restore directly, That is by design. I believe this suggestion was originally mine, and the intention is exactly to disable write access to arbitrary files via the backuppc user. As you wrote, if you don't want that restriction, leave out at least the '--sender' parameter. In this case, you might as well leave out the parameters altogether and just allow /usr/bin/rsync (with any parameters). In fact, I would even suggest narrowing down the allowed command further yet, if that wasn't tedious to implement and maintain (and error-prone, because you will, at some point, forget to adjust it to a BackupPC configuration change). The problem is not that BackupPC somehow guarantees that you will be hacked. Fact is, if your BackupPC server *is* compromised, the attacker (local or remote) gets a free passwordless login into all the clients. For Bzzzz, that is a free root shell. No problem (not mine, anyway). For you and me, it's only an unprivileged user shell. With the '--server --sender' above, all that can be done with that (without a further exploit) is reading all files (including /etc/shadow -- that is basically why I would want to further restrict the allowed command). Without '--sender', you get *write* access to /etc/shadow (and everything else, of course), meaning you can change the root password. Well, that obviously gives you a root shell again. There are tons of other (more subtle) ways to do that, but this is the most obvious. Also note that you don't even need to be exploited. As Les pointed out, anyone who can trigger a direct restore can get this root shell. So, the question is, is everyone who can trigger a direct restore *supposed to* have root access to the client in question? Les also mentions that direct restores are more error-prone than, e.g., downloading a tar file with the files you want from the backup. In my experience, I often prefer to compare the current version with the contents in my backup before overwriting it - it may not be retrievable afterwards if it was modified after the last backup or turns out to have failed to be backed up recently for any reason. So I tend to disable direct restores. Should I ever need a complete restore, I'll do it from the command line anyway. Of course, your mileage may vary. Hope that helps. Regards, Holger ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
