There is a mistake that some people make when pointing simple rsync jobs to us - they preserve ownership but send files owned by root.
This actually works… They successfully back up their files to their account with 0:0 ownership.
But, of course, they are not root on our end so they either lose the ability to write or change the files… Or they lose the ability to read them at all.
The easy solution is this neat rsync argument —fake-super … but I guess you could make this mistake on purpose with permissions that allowed read access to all … and successfully create write once, read, only backups…
I am extremely confused by this, as this seems like at least a bug if not a security issue. If I am not running as root on your server, how am I getting files owned by root at all? A normal user can't just hand files to root, for a number of good reasons. As far as I remember, the behavior of rsync -a if the other side is not running as root is that it just doesn't save the ownership (as opposed to error; "work but the files are owned by root and can no longer be read" is not an option).
Maybe you have made some kind of special dispensation for this, as it would improve the situation for backup purposes, but then it would seem like you got it wrong in a way which I would find super confusing; and, like, are you saying any files owned by users other than root but with other elevated use are fine?
Forgive me ... my lead engineer has rebuked me for mis-remembering this ...
It wasn't people preserving ownership and creating 0:0 files, it was people preserving permissions and sending us chmod 0000 files.
They were root on their end so their broken permissions worked but as soon as they hit their rsync.net filesystem, the 0000 permission meant they could no longer read it.
I think my original idea is still possible: you could do this on purpose (perhaps with 0400 permissions) and create write-once backups on any remote rsync host.
hmm this still seems like a bug to me. File ownership and file permissions are a filesystem construct. Whether you use chmod 777 or 755 doesn't change a file's md5sum, for example. It's up to your service to not apply file permissions that don't make sense. If backups are write-only with no mechanism for reading they may as well be to /dev/null
We don't have an app or an interface - it's just, as you say, a filesystem and there aren't any real guardrails. If your source files are 0000 and you 'rsync -a' you will achieve just that.
As for the original thought experiment, a one way chute for information that you can retrieve out of band is kind of interesting ... so Mallory can't gain anything with your credentials because you intentionally mis-wrote your backups but, of course, you could still formally attest your identity and retrieve them from (whatever organization).
Can I read more about this? Wouldn't these security bugs quickly fixed?
Containers have been widespread for quite some time now (Docker was first released in 2013, more than a decade ago) and this would seem like a basic bug. I'm willing to believe the kernel was buggy back then, but I would expect it is more robust now.
Instead of writing out "no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty" in the authorized_keys file; you can use the "restrict" keyword to enable all current and future restrictions.
Absolutely. I have used the heck out of this on systems since I found out about rrsync.pl and read through the code to make sure it was using a solid approach.
With a quick keypair generation one can quickly deploy read-only (and probably write-only although I've never tried that) access to select parts of a filesystem and do selective near-line backups of important files into a "history" host of sorts, and even leverage rsync's ability to use hardlinks in place of files that have not changed since the last run so no space is needlessly wasted backing up 400 copies of the same thing.
It was wonderful that I didn't have to write such a wrapper myself.
This actually works… They successfully back up their files to their account with 0:0 ownership.
But, of course, they are not root on our end so they either lose the ability to write or change the files… Or they lose the ability to read them at all.
The easy solution is this neat rsync argument —fake-super … but I guess you could make this mistake on purpose with permissions that allowed read access to all … and successfully create write once, read, only backups…