Subject: Re: sshd Change: PermitRootLogin = no
To: NetBSD Security Technical Discussion List <tech-security@netbsd.org>
From: Steven M. Bellovin <smb@research.att.com>
List: tech-security
Date: 09/05/2001 23:09:33
In message <20010906020119.A1FB3EA@proven.weird.com>, Greg A. Woods writes:
>
>Indeed I can pretty much invite you to chose your own favourite paper on
>generic computing systems security as evidence here since almost every
>such paper on the subject will show why SSH sessions should not allow
>direct root logins by default!
In fact, I tend to disagree. While your points (deleted for the sake
of brevity) are, in general valid, you tend to end up with a "polyhost"
that's not operationally realistic. People compensate for that with a
variety of hacks (often involving sudo) that tend to promote the
illusion of more security, but not the reality. And the reason for
that is that "privileged", non-root access to a machine is often
equivalent to root, but via a few extra, trivial steps.
We are not trying to administer single machines today. Rather, we are
dealing with "polyhosts" -- groups of machines (perhaps large groups of
machines) under common administrative control. I need to be able to
say "here's a new binary package (or pointer to a package); install it
on the following 300 machines". The ability to do that, in general, is
equivalent to root -- and it's an utterly necessary function. Put
another way, we're administering machines with TCP/IP backplanes. (I
used to say "with long, thin, yellow backplanes", which will show you
how long I've been muttering about about this.)
Greg, you do raise the very valid point of audit trails. Apart from
the fact that even today's single-machine case doesn't provide adequate
audit information (if a process sheds its control tty, there's no link
back to the original user; ditto for work-arounds that use cron jobs
and the like), if that's the only issue let's solve it. Maybe we can
pass audit trail info along in the ssh (or ssh' protocol), for example.
(Historically, I think that only Multics got the audit trail right, but
even networked versions of Multics were fundamentally stand-alone
machines; you didn't see large clusters of Multics machines
administered by one person or group.)
What is the right way to do audit trails, in today's environment? I
don't have a complete answer, but I strongly suspect that to do it
right, we need a much stronger notion of "session" than we have today.
You can find some very old thoughts of mine on the subject in a 1988
Usenix paper (http://www.research.att.com/~smb/papers/sessext.ps). It
would be interesting to redo that design in modern terms, since a lot
of the problems it tries to address are still with us.
--Steve Bellovin, http://www.research.att.com/~smb