* Maarten J H van den Berg wrote on Fri, Sep 07, 2001 at 19:46 +0200:
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 via ssh wrapper...] [...command="rsync"...]
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, this environment variable gets not set by OpenSSH. I cannot imagine that this is a big task to supply argv through the environment, I should make a patch, but time is missing as always. I have some wrapper scripts which evalute SSH_ORIGINAL_COMMAND. By this, it's possible to allow a well defined set of parameters. I used perl to filter that. If and only if the parameters are ok, the action is taken. I thought about some generic wrapper, which can be configured to allow a defined command set with some parameters, i.e. the fourth parameter can be arbitary as long as it's a number or whatever. Due to this, I still have some machines running non-open SSH servers...
("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.")
:) hihi, or even: "Here is your server. We just finished the audits of kernel 2.0.11 and printed a book with open issues which are not easy to fix. We estimated to additional years to be able to offer you a audited backup solution, but for now it's cheaper to use a DAT for each host." :)
Ohh, really? I just look from time to time :)
Hehehe. No, I myself insist on 200+ cron messages in my inbox daily ;-)) (NOT)
Well, I think about a netsaint plugin for such purposes. Each server could write a timestamp in a special file, i.e. /root/current_timestamp (each 5 minutes or so), and the plugin verifies the file inside the backup. It alerts if the timestamp is older as i.e. 24 hours or so. Well, I think this would take a few hours to implement...
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...
You're right of course. After all it shows up in pracitise that security through obscurity helps often against script kiddies.
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.
I think this would be difficult to parse. I made a example perl script which I attach to this mail. It gets a list of parameters of filenames (i.e. find /path | xargs ./perm.pl). It processes all files via lstat(2), puts some values into a hash. After that, it stores that hash on disk (just example code). Then it deletes the filelist and informations from memory. This is like on backup operations. After that, the scripts opens the disk file and load the hash back (meant for restore operations). It prints out chmod ; chown commands to restore the old state. Well, this isn't for production since it does eval on the permissions file ("filelist.dump"). This is dangerous if that file contains other perl statements, and by this the permission file is very security relevant :). But it's just an example. What to do with it? If someone would use such a thing, I would modify the script to process filenames from stdin (or to use find internally). The call could be "find /path -print0 | perl.pl -o filelist.dump". If started with "-o" it stops after writing filelist to disk. On restore, call "perl.pl -s filelist.dump" to set the saved permissions. Maybe some control on which files that should apply and so on. In this case, the script startes with reading filelist.dump from disk and does not print the chown/chmod commands but executes them. Well, and I think I would add support for the times (mtime...) which shouldn't be a problem, and some error handling of course. This is not much code in such a case, I think 2 hours programming (one of them for considerations) but 10 hours testing :) Maybe I'll get some statements; if someone is interested in such a script and if we find some tester I could implement it. Well, drop me a note.
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.
I'm not really sure if someone would use it, since if it's not integrated into a tool like rsync it's additional work to put it into the cronjobs. What do you think?
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.
I meant "client push" in the last sentence of course.
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.
What do you mean? I don't think it's possible to let an ordinary user doing backups. I meant, there is rootA on backupserver which is different from rootB on client B. In your case (client push) rootA could configure access to some path, and rootB on client B could manage the exclude lists or similar.
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...
Well, the backupuser don't need a shell account or password, so it's not a bad security risk I think. But it's much efford to copy all files local first, loseing all permissions. I think it's the same as client push to backup user on backup host directly.
Besides, a lot of things can break this setup. For instance, the machines have to be time-sync'ed for this to work well.
Well, ntp should run on every host all the time, my netsait checks that :)
Same here, It was very nice to exchange views on this subject. Speak to you later, I hope.
Thank you. Maybe we'll find the ideal solution? Hum. :) Someone with time to patch rsync here? Shouln't be too much work: instead of _doing_ "chmod mode, file" printf mode, file to some permission file - or similar. But on restore? Just `permission file` command substition? What with error handling... Well...
Oh, and: Have a nice weekend !
Same to you and the list! oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.