On 12/02/2010, at 4:18 PM, Daniel Pittman wrote: > James Gray <[email protected]> writes: > >> I've googled this one for a while and can't find any examples of people >> doing *system* file sync with rsync. So I thought I'd throw it out to the >> collective wisdom of SLUG. Here's the full story. >> >> We have a SuSE-based production application/DB server pair and a >> corresponding pair in a disaster recovery location (offsite, bandwidth >> consumption needs to be minimised). We need to sync a number of files >> between these servers and some require elevated (root) privileges at *both* >> ends. Here lies the problem; we don't allow remote root logins (via SSH or >> any other method either...sudo, console or nadda). >> >> I want to use rsync because of it's ability to transfer >> differential/incremental changes and thus bandwidth friendly, however any >> other tool would be fine too. However, due to the inability for root to >> login directly, how the heck do I synchronise particular files in privileged >> locations (like /etc/shadow)? > > ...if you allow this tool to write to /etc/shadow[1], just allow root logins: > you have added *nothing* by forbidding them. Why? An attacker with access to > the rsync tool can add an additional root user with a known password anyhow, > so additional "security" doesn't actually change the problem space at all.
I'm not going to get into the "allow root, or not to" holy war. This is a big multi-billion dollar company and the "security team" have decreed no direct root logins. End of story, it's not an option. Whether I agree with them or not is irrelevant, it's just not an acceptable solution in the environment I work. >> I can start whatever services I need at either end (like an rsync server) >> but the main thing is all files maintain the same owner/group/mode at each >> end. >> >> Ideas? > > Just use root, if you want to go down this path. See above. > Alternately, I would suggest using something like puppet which is designed to > do system management like this in an automated fashion; it is a completely > different approach, but one that will probably solve your underlying problem > without needing to change your security model so much. I've used bconfig before and was moving towards puppet when that employer decided to commit corporate suicide and ended my tenure (along with everyone else's!) before really getting stuck into it. This will probably be the long-term solution but for now we simply need something to make the auditors go away with happy thoughts. > [1] ...and, by implication, /etc/passwd, since the later isn't much use > without the former being updated too. Yep - we also need to sync /etc/group and a bunch of other application-specific fru-fru like CIFS passwords for /etc/fstab that are store root-readable (and no-one else) files too. The reason for highlighting /etc/shadow is that, unlike its /etc/passwd counterpart, is only root-readable ;) This is why using privileged accounts at both ends is necessary. Thanks for the input. Cheers, James
smime.p7s
Description: S/MIME cryptographic signature
-- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
