Red Hat Bugzilla – Bug 435776
BackupPC defualts should be more secure
Last modified: 2008-03-04 09:58:18 EST
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
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):
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.
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.
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.
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.