Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#56008 - [rsync] ProtectHome=on breaks rsync on homedirs

Attached to Project: Arch Linux
Opened by Geert Hendrickx (ghen) - Monday, 16 October 2017, 08:44 GMT
Last edited by Sébastien Luttringer (seblu) - Wednesday, 01 November 2017, 10:20 GMT
Task Type Bug Report
Category Packages: Extra
Status Assigned   Reopened
Assigned To Christian Hesse (eworm)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 2
Private No

Details

Description:

ProtectHome=on was added to rsyncd unit file in version 3.1.2-4

This obviously breaks rsyncing of home directories between servers (it can no longer even list the /home/* directories).
Although this flag is useful for network services in general, I think rsyncd is a bad candidate.
Please rollback.

This task depends upon

Comment by Christian Hesse (eworm) - Monday, 16 October 2017, 08:55 GMT
I would like to keep this change. Would be nice if attackers can not access home directories in case it is exploited. Most people do not serve home via rsync I think.

If you want to enable access to home directories create a drop in replacement file /etc/systemd/rsyncd.service.d/home.conf with these lines:

[Service]
ProtectHome=off

Is that a way to go for you?
Comment by Geert Hendrickx (ghen) - Monday, 16 October 2017, 10:22 GMT
Yes, I deployed that already, but it's quite cumbersome if people don't know where to start looking.

I do agree it's a very useful protection in general, and I think many more daemons should get it by default, but rsync as a backup tool is probably a special case.
Comment by Holger Rüdiger (manti7) - Wednesday, 18 October 2017, 06:50 GMT
I disagree that the /etc/systemd/rsyncd.service.d/home.conf is a good solution. The reason is the "man rsyncd.conf" with this content:

[ftp]
path = /home/ftp
comment = ftp export area

Thank you for your good work and security thinking! But I think the example from the manual should work.
Comment by pezcurrel (pezcurrel) - Monday, 23 October 2017, 08:01 GMT
I agree with Geert and Holger. I use rsyncd to backup 2 boxes over a local network and I think it's a common use case. It took me a lot of time to understand why the various home directories didn't get saved. Moreover, particularly in a system-wide backup scenario like mine, where /home/* is just one of many directories to be saved, one can easily fail to even notice home directories are not getting saved (I noticed it only this morning). I would recommend rolling back, or, at the very very least, add a note to https://wiki.archlinux.org/index.php/Rsync#rsync_daemon
Comment by pezcurrel (pezcurrel) - Tuesday, 24 October 2017, 18:32 GMT
I added the note to the wiki and someone improved it later.
I still would recommend rolling back, but if this is not going to happen I think it would be good if the package warned users during installation/upgrade about the issue with home directories that "ProtectHome=on" introduces, maybe pointing them to https://wiki.archlinux.org/index.php/Rsync#rsync_daemon.
Comment by Christian Hesse (eworm) - Thursday, 26 October 2017, 11:30 GMT
We have instructions in wiki and I added a post-upgrade info.
Comment by Sébastien Luttringer (seblu) - Monday, 30 October 2017, 11:17 GMT
Hello Christian,

I had also several rsyncd broken by these change. The logic of disabling accesses to some arbitrarily chosen directories because of potential bugs could be applied to a lot of daemon, like http servers and others, and will create useless configuration difficulties.
Rsyncd is a file transfer daemon, adding these options break the regular way of using rsync for theoretical security improvements. That's not the expected behaviour! Not to mention that data can be everywhere else, and with the same logic, we should forbid everything. That already what we do by not starting the daemon automatically (like Debian, etc) after installation.

Comment by Christian Hesse (eworm) - Monday, 30 October 2017, 11:26 GMT
*sigh*

Looks like this concerns more people than I initially thought. Ok, let's undo the change.

How about ProtectSystem=full? Do we want to keep this or drop it as well?
Comment by Sébastien Luttringer (seblu) - Wednesday, 01 November 2017, 10:40 GMT
Sorry Christian for not answering as fast.

ProtectSystem=full is also limiting the expected behaviour of rsyncd; there are read only / write only options in configuration file. If we keep this in the service, this will perturb configuration.
PrivateDevices is also faking the view of the file tree by rsyncd. I think we should not do that too, rsyncd is a file system copy transfer which should not be faked by its service file.

NoNewPrivileges looks like improving security without breaking.

So my opinion would be to rollback at least ProtectSystem, ProtectHome and PrivateDevices.
Comment by pezcurrel (pezcurrel) - Saturday, 04 November 2017, 11:26 GMT
I agree with Sébastien.
I think the extra layer of security one can get by editing the unit file with ProtectHome/ProtectSystem/PrivateDevices=yes in those cases where it could make sense could be mentioned in a note on the wiki under the "Rsync daemon" paragraph, but should definitely not be enforced upon users by the package's unit file since this interfere with the daemon's expected behaviour.

Loading...