Hi, Please send questions to the list, not to me. On 4 Sep 2003 Atom 'Smasher' <atom@suspicious.org> wrote:> i've been trying to find a good answer for this, but pretty much all > i've found is disagreement on what level of insecurity is > acceptable.... > > the problem arises when trying to use rsync as root. > > obviously, allowing root logins through ssh (or any protocol, really) > is best avoided.Can you explain why you hold that opinion?> of course, there are things that might need to be backed up > through rsync that can only be had with root permissions. > > there are several hacks i've found that play with known hosts and > their keys, or scripting which side initiates the transfer, etc. they > all try to bypass the problem, but most really don't fix it. > > here's my dream fix: > > add a new option to rsync: -su(The short-options -su already have meanings; you must mean --su.)> let's say i want to mirror the /etc directory, but leave root login > disabled... wouldn't it be cool if i could: > > rsync -var --delete -e ssh -su \ > atom@suspicious.org:/etc/ \ > /usr/backup/suspicious/etc/ > > and then, it would prompt me for the root passwd and (assuming that > i'm in the wheel group) continue the rsync as if i logged in as root.Can you please explain how sending a root password over an ssh channel is more secure than directly logging in as root? Indeed, for some cases (such as the user 'atom' being compromised) it seems less secure. If you really want to do this you can probably do it using an rsync wrapper script invoked through --rsync-path.> if i was any good in C, i'd at least prototype it for you. anyway, if > you think that would be a good addition to rsync, i know i'd enjoy > seeing it in a future release. > > anyway, maybe some of my open-source projects will be of help to > you.... http://business-php.com/opensource/Regards, -- Martin
--On Friday, September 05, 2003 12:45 PM +1000 Martin Pool <mbp@sourcefrog.net> wrote:> On 4 Sep 2003 Atom 'Smasher' <atom@suspicious.org> wrote: > >> obviously, allowing root logins through ssh (or any protocol, really) >> is best avoided. > > Can you explain why you hold that opinion?Speaking as a security weenie, the problem is the utter lack of an audit trail. "root" isn't a person, it's a role. If you allow direct role logins, you have no idea what person is responsible. I don't, however, think that the rsync protocol is the right place to fix it(speaking about normal rsync +rsh/ssh/whatever, not the rsync daemon). Fixing the security issues with the daemon is a much more difficult proposition. Possible options: - Don't allow root to log in, require su, sudo, or a similar mechanism (such as RBAC in Solaris). This makes rsync unhappy. - Create multiple UID 0 accounts, one per person. Works, but not the most manageable of solutions. - Only allow root logins from cryptographically authenticated trusted hosts. This assumes you can trust the audit logs of host A to figure out who logged in to host B. Current SSH implementations are less than stellar about this, but the protocol does allow it. - Allow cryptographically authenticated remote users (such as kerberos roles - user.admin@dom.ain) to log in as role accounts. Sadly, I don't know of anything but kerberos that really does this well. SSH can do something similar using RSA/DSA auth and logging the key fingerprint. - Allow role based logins based on user credentials (via PAM/NSS, or other mechanisms). I'd log into the remote host as root, be authenticated as carson, but logged in as root. The usual way to shoehorn this in is to overload the username (e.g. log in as the user root/carson). -- Carson