Bug 435776

Summary: BackupPC defualts should be more secure
Product: [Fedora] Fedora Reporter: Joe Krahn <krahn>
Component: BackupPCAssignee: Johan Cwiklinski <fedora>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 6   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-03-03 21:24:38 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Joe Krahn 2008-03-03 20:08:09 UTC
Description of problem:
BackupPC defaults do not properly address security, which are mostly left up to
the end-users by the BackupPC developers. The main problem is that the easiest
configuration to implement using the existing defaults is to use unrestricted
remote-root access from a non-root user. In addition, the server is
CGI-accessible without SSL, which makes it easy to gain administrative access to
the BackupPC server. Some people might even set up CGI to be accessible remotely.

In general, the backup server should not have unrestricted remote write access
to client machines. At the very least, it should not be able to write to system
files.

One approach is to set up an SSL tunnel to access rsyncd on the client with
access only to localhost, but that still leaves rsyncd open to a local non-root
user. The other problem with rsyncd is that SElinux restrictions make it
unusable, unless those restrictions are disabled, but they are there for a reason.

My initial solution was to set up an ssh key with a command= option, so that the
remote access can only be used to initiate a backup. The command uses sudo, and
has the sudoer config restricted to only allow rsync with --send. However, it is
hard to enforce access restrictions on the rsync process.

I have set up an even better system using rsyncd over a shell (see "USING
RSYNC-DAEMON FEATURES VIA A REMOTE-SHELL CONNECTION" in the man page). The
disadvantage is that it requires a few code changes, because the RsyncP client
doesn't support this. It is a really good method because it allows for detailed
access restrictions, plus the safety of chroot. Also, running rsyncd over a
shell is not restricted by SElinux, so an actual rsyncd daemon can still be run
with the extra security. I can attach my diffs here if the maintainer(s) want to
try it out.

The configuration has to be done manually, so it may be sufficient to have some
documentation covering various options and their security risks.

Version-Release number of selected component (if applicable):
3.1.0

How reproducible:
always

Steps to Reproduce:
1. set up BackupPC using the insecure examples given by BackupPC's documentation.
2. get your sever compromised by a malicious hacker, and risk losing both client
and backup copies of important files.
3.
  
Actual results:
poor security

Expected results:
good security

Additional info:
It might be good to develop a BackupPC client configuration script. To aid in
setting up clients, it would be good if the server's public key was accessible
over the HTTP/CGI on the server.

Comment 1 Johan Cwiklinski 2008-03-03 21:24:38 UTC
I'm not going to do this.

It's a configuration issue, not a packaging one. You should contact upstream to
tell them you point of vue, security considerations are BackupPC related, and
should be provided by the dev team, not in a Fedora package I guess.

Anyways, if you have ideas to improve this package, feel free to submit me
relevant spec files and patches.


Comment 2 Joe Krahn 2008-03-04 14:58:18 UTC
OK, that is reasonable. I thought it was worth sending in because packagers
sometimes will add security enhancements, and perhaps someone experienced with
security issues would get a chance to look at this. For now, I will try to get
the BackupPC dev team to better address this.