Re: [BackupPC-users] error in rsync protocol data stream (code 12) (Restoring)

[Bzzzz]

On Thu, 16 Nov 2017 12:22:00 -0600
Les Mikesell  wrote:

> No, but when doing a restore for any reason other than accidental
> complete deletion of a file or directory I nearly always restore to a
> different location and compare things instead of overwriting the
> existing current versions anyway.

Ok, I clearly see your point and value it as a wise thing to do when you
only have BPC as a safety net.

> Your hypothetical educated user […]

Well, this is relatively different as BPC is shot over night once per
24Hrs. In fact, they only use it for former docs they mess with; current
ones, wrecked during the same day must be addressed by one admin, as
they must be extracted from an hourly FS snapshot.
But surprisingly, this is a very rare operation; which may be tied to
the fact that admins interventions are strictly limited to the morning,
no matter what (except servers breakdown.)

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

Re: [BackupPC-users] error in rsync protocol data stream (code 12) (Restoring)

[Les Mikesell]

On Thu, Nov 16, 2017 at 12:08 PM, B  wrote:
> On Thu, 16 Nov 2017 10:45:40 -0600
> Les Mikesell  wrote:
>
>> Yes, but things have to be very, very screwed up to get to the point
>> where the user can't fix it with a tar download through a browser
>> followed by an appropriate restore command.  When things have been
>> broken that badly it may be time to let someone else fix it.  And if
>> you are restoring a whole system you have to configure that part again
>> anyway.
>
> Well, I can concede this to you, but it is a tiny bit extreme.
> (do you climb mountains free hands with pitch black glasses and a
> chopper waiting for you at the top ?;)

No, but when doing a restore for any reason other than accidental
complete deletion of a file or directory I nearly always restore to a
different location and compare things instead of overwriting the
existing current versions anyway.  And it is not at all difficult to
download a tar image and restore it where you want.  Your hypothetical
educated user that knows enough not to overwrite good data should not
have a problem with it.

-- 
   Les Mikesell
 lesmikes...@gmail.com

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

Re: [BackupPC-users] error in rsync protocol data stream (code 12) (Restoring)

[Bzzzz]

On Thu, 16 Nov 2017 17:57:59 +0100
Holger Parplies <wb...@parplies.de> wrote:

Whoops, wrong from: (and strange setup), putting this back in the list.

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

Ok, so develop it, this way I could understand what's so terribly wrong.

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

Re: [BackupPC-users] error in rsync protocol data stream (code 12) (Restoring)

[Bzzzz]

On Thu, 16 Nov 2017 10:45:40 -0600
Les Mikesell  wrote:

> Yes, but things have to be very, very screwed up to get to the point
> where the user can't fix it with a tar download through a browser
> followed by an appropriate restore command.  When things have been
> broken that badly it may be time to let someone else fix it.  And if
> you are restoring a whole system you have to configure that part again
> anyway.

Well, I can concede this to you, but it is a tiny bit extreme.
(do you climb mountains free hands with pitch black glasses and a
chopper waiting for you at the top ?;)

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

Re: [BackupPC-users] error in rsync protocol data stream (code 12) (Restoring)

[Jamie Burchell]

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>; B <lazyvi...@gmx.com>
Cc: backuppc-users@lists.sourceforge.net
Subject: Re: [BackupPC-users] error in rsync protocol data stream (code
12) (Restoring)

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

Re: [BackupPC-users] error in rsync protocol data stream (code 12) (Restoring)

[Holger Parplies]

B 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 B, 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/

Re: [BackupPC-users] error in rsync protocol data stream (code 12) (Restoring)

[Les Mikesell]

On Thu, Nov 16, 2017 at 10:37 AM, B  wrote:
> On Thu, 16 Nov 2017 10:21:49 -0600
> Les Mikesell  wrote:
>
>> damaging) direct restore.  But the admin should know what to tweak if
>> he does need that massive restore.
>
> Yup, and the problem is: in this configuration, you *need* an admin
> intervention to fix a restore,

Yes, but things have to be very, very screwed up to get to the point
where the user can't fix it with a tar download through a browser
followed by an appropriate restore command.  When things have been
broken that badly it may be time to let someone else fix it.  And if
you are restoring a whole system you have to configure that part again
anyway.

-- 
   Les Mikesell
lesmikes...@gmail.com

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

Re: [BackupPC-users] error in rsync protocol data stream (code 12) (Restoring)

[Bzzzz]

On Thu, 16 Nov 2017 10:21:49 -0600
Les Mikesell  wrote:

> damaging) direct restore.  But the admin should know what to tweak if
> he does need that massive restore.
 
Yup, and the problem is: in this configuration, you *need* an admin
intervention to fix a restore, when the other solution easily leads
to: user = BPC user <=> each user can backup/restore from 1 file
to his whole $HOME (if needed) without having to ask the admin to do so.
This means informed users, but IMHO the time taken to train them is, by
far, less pain than being disturbed any time.

Of course YMMV as this depends on company policy, some don't want any
direct contact between user and data (well, it also depends on admins,
some want to control everything, others not;-p)

Jiff

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

Re: [BackupPC-users] error in rsync protocol data stream (code 12) (Restoring)

[Les Mikesell]

On Thu, Nov 16, 2017 at 3:19 AM, Jamie Burchell  wrote:
> Running as a restricted user is actually part of the BackupPC
> documentation. It just neglects to mention that doing so as described
> means restores are blocked.
>
> Having a non root user with sudo permissions to just rsync with the
> "--server" param works fine for backup and restore.

Maybe that should be documented more clearly.   I could see where the
read-only version might be useful in typical operation where the host
'owner' could still use the web interface to download copies of old
files or directories but could not do a massive (and potentially
damaging) direct restore.  But the admin should know what to tweak if
he does need that massive restore.

-- 
   Les Mikesell
 lesmikes...@gmail.com

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

Re: [BackupPC-users] error in rsync protocol data stream (code 12) (Restoring)

[Jamie Burchell]

Running as a restricted user is actually part of the BackupPC
documentation. It just neglects to mention that doing so as described
means restores are blocked.

Having a non root user with sudo permissions to just rsync with the
"--server" param works fine for backup and restore.

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

Re: [BackupPC-users] error in rsync protocol data stream (code 12) (Restoring)

[Bzzzz]

On Wed, 15 Nov 2017 23:29:58 -
Jamie Burchell  wrote:

> Because you'll seldom find any good advice that advocates doing
> anything as root.

You misread it.

Doing stuffs as root when it can be done by a regular user, or a sudo
user _can_ be a risk (although I don't know any real admin that hasn't
at least one or two consoles opened as root.)

Everybody with a large practice of Linux has been goofing at least one
time - I made a rm -r * as root on the root of the master disk (thanks
BPC !), but you can also do tough shit as a user (such as rm -r ~ /dir
watch the space between ~ and /dir, meaning you're removing your whole
$HOME + /dir !)

And in the particular scheme of BPC, where's the risk?
root does launch rsync and recover files or parts of files into a
controlled, so what?
This isn't a _console_ risky line command order, this is part of a known
automatic process !

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.

Rule of thumb: don't get creative with a well known (and described)
process.

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

Re: [BackupPC-users] error in rsync protocol data stream (code 12) (Restoring)

[Jamie Burchell]

Because you'll seldom find any good advice that advocates doing anything
as root.

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

Re: [BackupPC-users] error in rsync protocol data stream (code 12) (Restoring)

[Bzzzz]

On Wed, 15 Nov 2017 22:48:01 -
Jamie Burchell  wrote:

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

Why on earth did you use that instead of let it to root !?
in which case, restoration by a user doesn't cause any problem.

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

[BackupPC-users] error in rsync protocol data stream (code 12) (Restoring)

[Jamie Burchell]

Hi!



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, as I’m getting the following error:



Restore failed on X (rsync error: error in rsync protocol data stream (code
12) at io.c(629) [sender=3.0.9.8])



I just logged in to the client, and sure enough have this in the secure
logs:



Nov 15 22:39:54 x sudo: backuppc : command not allowed ; TTY=unknown ;
PWD=/home/backuppc ; USER=root ; COMMAND=/usr/bin/rsync --server
-slHogDtprRe.iLsf



I’m assuming this is because the “--sender" parameter isn’t used here.



What’s the best way to fix this? Should I simply remove “--sender" from the
sudoers config and should this be added to the documentation?



TIA



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