rsync // su

[Martin Pool]

On  4 Sep 2003 Carson Gaspar <carson at taltos.org> wrote:

> --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.

... if you do the transitions to superuser in a way that doesn't
record who did them, yes.  Whether that transition occurs at login or
later is incidental to whether we know who did it.

The real problem seems to be that sudo/su emits a log message saying
which user is becoming root, and ssh by default does not know who the
remote user is.  However, as you say, if you get SSH to log the public
key which was used to become root,or use Kerberos, then you have quite
good identification.  

Obviously password authentication is not enough; it could be anyone
who knows the assword.

The other root (heh) problem is that people are logging in as root
when probably all they need is somethng like CAP_DAC_READ_SEARCH, the
ability to read all files.  Going to some kind of pam modules that set
the right capabilities would be a better fix.  This too requires no
(or few) changes to rsync.

> 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.

It can easily be done by writing your own script which you call
instead of ssh.  Anything that ends up giving a socketlike connection
will do.

> - 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.

Either of those sound good.  Presumably you have sufficiently few
people with root access that you can keep track of their keys.

-- 
Martin