Why doesn't rsync have a chroot option when started via SSH?

[sagb]

Suppose you want a multiuser rsync server in a zero-trust environment. You need a chroot.

1. You could run rsync in daemon mode or "chain-proxy" as described under "USING RSYNC-DAEMON FEATURES VIA A REMOTE-SHELL CONNECTION" in the man rsync. The major drawback is its reliance on its own password authentication instead of today's industry-standard SSH keys. Even if you find a trick to overcome this, the overall setup would be a security headache.

2. Rsync in non-daemon mode can be started from a chroot by an external program. This means the user will see the executable and libraries lying around, which might confuse them or provoke them to tamper with these files and attempt to escape.

3. As a final nail in the coffin, you might start filtering user input, trying to restrict them to specific directories, either with rrsync or, say, GNU Rush regexes. This approach is quite naive and only viable in an enterprise setting, but not against targeted attacks on the internet.

The solution would be the capability to chroot+chdir+setuid without daemon mode, controlled by command-line options that are forcibly set by sshd or a restricted shell.

The downside is that you need to run rsync as root, either using the SUID bit or running it from the aforementioned Rush, which is SUID. To me, this seems more manageable than the scenarios described in points (1), (2), and (3).

[michaelmess-de]

rsync just runs rsync as a remote command in a remote shell via ssh and passes some parameters to it so that the remote process knows what to do (being a server):

When testing a new feature I executed:
./rsync    -vvan --nice-value=+4 --nice-local-value=-2  --nice --bwlimit=48K --rsync-path=/home/michael/github/rsync/rsync . michael@localhost:~/garbage-test-path/ 
and rsync logged what it did to start the remote process:
...
opening connection using: ssh -l michael localhost /home/michael/github/rsync/rsync --server -vvnlogDtpre.iLsfxCIvu --bwlimit=48 --nice-local-value=4 . "~/garbage-test-path/"  (11 args)
...

You see: using rsync it is possible to execute any executable on a remote shell as it is possible by just using ssh directly.
If rsync would create a chroot environment, that would only protect from bad things that rsync itself might be doing, but not from what might happen when executing any other remote command or executable that is also available at the remote shell besides of rsync.

Thus the best thing is to create a chroot environment, run an sshd there and provide rsync and all required libraries.
For security reasons it is important that the binaries are readonly for the logged on user. This could be provided by file permissions (for non-root-users) or by a readonly file system (even root couldn't write to it or tamper with the files).
Thus I see the mentioned option 2) as most viable way to achieve this.

By the way, giving rsync SUID root access would arise the need to ensure that any root rights are dropped when not needed anymore and to verify they're really gone (sounds funny, but is really important - that has been exploited already) before starting doing any work for any non-root user while leaving root rights unchanged if the user has actually logged in as root.
Failure to do that right might be a high security risk, possibly giving an attacker root access to tamper with any files on the file system, not limited to the files the logged-in user usually can access.
Thus I would not recommend to give rsync SUID-root rights at all.
This to ensure that rsync is restricted to the permissions the logged-in user has, even in case there are (still unknown) bugs or exploits that might be used by an attacker.

[sagb]

I don't see how your remark about SSH is relevant. The question here is about rsync features, not remote shell security. Depending on the design requirements, SSH can either provide a full-featured shell or be restricted to a specific rsync invocation in .ssh/authorized_keys:
restrict,command="rsync ..."

Rsync per se is already extravagant enough in a modern user-facing service. We keep it as a funny nostalgic feature. Option (2) with executables inside would look like '90s FTP chroots, which would be too extravagant/ugly/not funny.

When you say "verify root rights drop", do you mean that setuid()/setgid() can return 0 but privileges might still not be dropped?

Meanwhile, we ended up with a patch to rsync that implements exactly what's described in this conversation: https://github.com/sagb/rsync-super

[michaelmess-de]

I was thinking the comment was about a new feature request, but the feature discussed here is already implemented.

The exploit about failed setuid() i mentioned could only happen if the code didn't check for the result.
In rsync the result is checked and if unsuccessful, the process exits. So we don't have to worry.

Maybe in future we should add a comment to open discussions about a new feature, when a feature is already implemented and accepted (best with the rsync version), just for information.

[sagb]

Well, 1.5 years ago it was a feature request.
Since then, I've implemented it but didn't try to adapt it for merge to upstream rsync by making the chroot arguments non-positional and optional. And I doubt the maintainers would accept a PR, given the alleged number of existing ways to achieve a "similar" result.