Thank you very much for this post, it’s exactly what I was looking for!

Firstly fantastic article. I’ve read a lot of them on the topic of Rsync backups and this is by far the best I have found. Unfortunately I had to come to the solution of using the Rsync daemon to make everything read-only before I was able to track down your article in Google. Oh well. :)

However you say this:
"If this works, then you are allowing root login over SSH on your source system, which is horribly insecure."

I’m guessing what you’re saying here is that it’s bad because a compromise of the destination system would mean a compromise of the source system(s).

But the solution you give, while better still would allow anybody who had compromised the destination system to grab all of the private keys on the source system(s). I’m a linux system admin noob, but wouldn’t this situation be almost just as bad? At the very least doesn’t it mean that the attacker can pretend to be the source machine and connect to anything that it can connect to?

On another note, I discovered a "Mark II.V" while researching this topic. A number of sites recommend using ’sudo rsync’ along with a rsync sudoers restriction as a safer alternative to giving root access. However what they didn’t realise is that their sudoers restriction is meaningless because the user can just use ’sudo rsync’ to read and then overwrite their sudoers file. You may wish to add this to your fantastic article.

This design is very bad. With this setup you are giving away free root access to any user on your system.

/etc/rsyncd.conf is world-readable, so anyone could determine your "wholefs" block and start rsyncing everything from localhost.

This could happen by a user that has SSH access, login and then start rsync’ing from localhost. He could rsync your shadow file and start john the ripper. Basicly he can copy your entire filesystem and do whatever he likes.

It can also happen remotely by a badly protected website such as a compromised Joomla installation or an older version of phpMyAdmin.

Just because your rsyncd is read-only doesn’t make it safe. It only prohibits from writing files, but beeing able to read any file (includig password files) is just as insecure.

Tozz is right, this technique gives full read access to the whole filesystem to anyone who has access to the source server.

This means normal users can read database passwords stored in php scripts owned by other users (therefore gaining read/write access to the victim’s database), for example, or like Tozz said copy and crack the shadow files.

You should only use this method if you 100% trust all users that may log-in on the machine (and if they mutually trust each other).

This should really be noted in the article, as a warning.

The issue is that not just an intended user can achieve this access, but every user.

If every user was meant to have read-only access to every file on the system, there would be no need for the ’read’ flag in chmod.

Many automated backups involve a system which provides some kind of public service, which in turn is likely to have its own user account. Normally, this provides a level of protection. But even a chroot would not stop this as it uses a socket.

If you run a web server under its own account, and there is a flaw in the software it uses, through this setup a hacker can read every file on the system, giving them the ability to further increase their access. Normally they would not be able to do this.

Now, is a random hacker likely to figure out what you’ve done, and how to exploit it? Probably not; but the possibility is there. That is what we’re worried about.