On Friday 07 September 2001 17:50, you wrote:
* Maarten J H van den Berg wrote on Fri, Sep 07, 2001 at 15:44 +0200:
rsync -e ssh -ogptLrcv --stats --partial --exclude=logs/ --safe-links /etc/foobar root@www.xxx.yyy.zzz:/home/backups/Host-AAA/
via
?
command="rsync --server -vLogtprc --partial --safe-links . /home/backups/Host-AAA/",no-port-forwarding,no-X11-forwarding,no- agen t-forwarding 1024 35 123456789....................123456789 root@aaa.bbb.ccc.ddd
I'm not even sure if this safe behaviour is enforced by rsync, or by sshd. I think, by sshd. My guess is, the server 'parses' "/home/backups/../", which obviously gives "/home/", compares that to its "enforced" command inside authorized_keys, and silently disregards the requested path.
Well, actually it's like that. SSHD ignores the parameters of the client command completely and uses the parameter list from command="". sshd delivers the parameters in SSH_ORIGINAL_COMMAND (or similar), openssh seems not to have that nice feature.
Thanks for clearing that up. However, this IS in fact openssh... Or do you just mean that openssh does the same thing but does not provide the original command in SSH_ORIGINAL_COMMAND ?
Yep, but an attacker who steals a root key from a host can connect from that host too, so I don't see a big improvement currently.
true. [...]
[...]
Not that I did look into. Besides, I sadly lack the c / c++ skills needed for auditing it myself... :-\
Well, and I don't think customers would pay for it :) Would become an expensive backup :)
Hehehe... you said it. :-) ("Here is your server. To be totally sure, we just audited all of the kernelsources 2.4.9. We just thought it was a nice addition to the service-level you usually get from us. And ehm... here is your bill.")
Indeed. But mailing the timestamps of /home/backups/* gives at least an indication whether the backup still runs. Not that that is foolproof...
Ohh, really? I just look from time to time :)
Hehehe. No, I myself insist on 200+ cron messages in my inbox daily ;-)) (NOT)
These servers are colocated, not easily accessed. For us, any user-intervention was unacceptable.
Yes, the old problem. Anythink w/o user interaction can be easier compromised as when done with user interaction. After all, I don't think it makes a big difference if an attacker has to wait until the disc get's inserted. Even with some smartcards or whatever this won't help, since it's not possible to be sure that the smart card reading host is safe and not compromised.
Yes... But if you think not in absolute terms ("totally secure") but relative terms ("one level more difficult to break than before"), every little bit can help. But like I said, someone determined...
For backups like that rsync job, it would be nice to have some mode in which the permissions get saved in some ordinary file. In that case the backup job wouldn't need root permissions. But restore operations would be more complex.
You know, that is *exactly* what my first approach to this problem was. Like taking a ls-lR list, feed that to some nice script that replays all chmod/chown commands neccessary to put things back to how they were. In the end I could not find anything that does this, and I already told you about my limited programming skills so I dropped that idea. However, this is really something I'd like to see as a tool. Maybe someday, someone will write it... In that case, no more need for elevated priviledges for backups. Restore operations more complex is not a big issue; I rarely ever need to restore anything, in practice. YMMV
What are your reasons for doing client "push"?
Ehm... Let me think back... One thing I can mention, if one of the hosts is compromised, it stays confined to that host (unless the rsync setup has securityflaws like you describe above, that is). With server-pull, IF the backupserver should get compromised, you lose everything, as that server has access to ALL those clients at some level (root or unpriv).
Yep, good point...
Another point is that we need to backup files from many different filesystems, like /var, /usr, /home, /etc. That is difficult to control.
As long as adminstrated by a single person I don't see a difference, but at least if they admin of the backup client has no shell access to the baskupserver client pull is configurable by him.
If it's root who does the backup, there is no real problem (but that may not be advisable). If it's an ordinary user who does the backups, it could create havoc on all the different permissions one has to set up. One could also run scripts on the client and the server simultaneously, on the client side a root-cronjob copies & chowns some root-owned files to a special backup dir which is only readable by the backup daemon, and the server pulls them with a non-priviledged account. But it is doubtful that gives you any more security (or even, less!) The whole point of -for instance- /etc/shadow is that it is NOT readable by anyone... Besides, a lot of things can break this setup. For instance, the machines have to be time-sync'ed for this to work well.
So far it was very nice and productive to discuss it with you. Thank you.
Same here, It was very nice to exchange views on this subject. Speak to you later, I hope. Oh, and: Have a nice weekend ! Maarten -- Maarten J. H. van den Berg ~~//~~ network administrator van Boetzelaer van Bemmel - Amsterdam - The Netherlands http://vbvb.nl T+31204233288 F+31204233286 G+31651994273