rsync // su

[Carson Gaspar]

--On Friday, September 05, 2003 12:45 PM +1000 Martin Pool 
<mbp at sourcefrog.net> wrote:

> On  4 Sep 2003 Atom 'Smasher' <atom at 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 at 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