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/
