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