Subject: re: sshd Change: PermitRootLogin = no
To: Bill Studenmund <wrstuden@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: tech-security
Date: 09/05/2001 22:01:19
[ On Tuesday, September 4, 2001 at 12:16:15 (-0700), Bill Studenmund wrote: ]
> Subject: re: sshd Change: PermitRootLogin = no 
>
> On Wed, 5 Sep 2001, Greg A. Woods wrote:
> 
> > [ On Monday, September 3, 2001 at 17:06:18 (-0700), Bill Studenmund wrote: ]
> > > Subject: re: sshd Change: PermitRootLogin = no
> > >
> > > No, for two reasons. 1) We do have things other than the physical console
> > > marked "secure" in /etc/ttys by default.
> >
> > "We" do?  I can not find any such example in -current....  Were there
> > past examples?
> 
> Uhm, how about src/etc/etc.i386/ttys revision 1.12, or
> src/etc/etc.macppc/ttys revision 1.3? I just did a cvs update, and these
> are the current revisions.

In those revisions of those files all of the _enabled_ "secure" ttys are
directly and implicitly related to the physical console.

If you're going to try to claim that a disabled or commented out entry
is an indication of a policy guideline then I think you'd better think
again!  The point here is that out-of-the-box NetBSD will not actually
allow the root account to be directly accessed unless the tty is marked
"secure", and obviously it must also be enabled at the same time too!

To put a somewhat more sarcastic slant on things though I'd have to
suggest that anyone using i386 or macppc as examples of good server
platforms with inherent security features is either blue-sky dreaming or
making other unstated assumptions about actual implementations!  Now if
one of those examples had been VAX, then things might be different!  :-) ;-)

> The whole point of this thread is a disagreement about that policy. It did
> not used to be a written one, but an unwritten one. And it ended up being
> a different policy for different people.

Yes, of course it's an unwritten policy.  However the way I and others
have interpreted it though is very VERY much in line with written
guidelines published by many different computer security experts, and
indeed is logically in conformance to the very most generic guidelines
about maintaining good computer security.

You and the other's who've been trying to make a different
interpretation seem to be making some very non-standard and unstated
assumptions about the environments you're considering and the 

> By your understanding of the policy NetBSD has had. By my understanding,
> we have required these logins happen over "secure" ttys. And in my book,
> ssh connections (with the right levels of security) count as "secure",
> thus there was no inconsistency.

Now that you've stated one of your assumptions ("ssh ... with the right
levels of security") it's easier to show that your interpretation of the
policy guideline cannot be safely used for the generic default
out-of-the box system configuration since it should be clearly obvious
that the default configuration of ssh on NetBSD does not have "the right
levels of security" to meet your requirements because it would allow
anyone to login to the "root" account with a simple multi-use password.

I.e. yes, if you've re-configured SSH to require valid RSA keys, or
one-time passwords, or secure tokens, etc., then you might find those to
be sufficient to allow direct root logins over SSH.  However since SSH
doesn't come that way out-of-the-box so must it NOT allow direct root
logins out-of-the-box.

> Why? Do you have papers indicating that ssh-protected sessions doing
> direct root connections are insecure?

Yes, of course!  :-)

In fact it's actually much simpler than you're hinting at, and has
absolutely nothing whatsoever to do with SSH specifically -- the same
issues apply for any session authentication, authorisation, and/or
privacy mechanisms that might be used over any TCP/IP or similar style
of network (i.e. where the physical location of a given session origin
is not in general as easy to pinpoint as it is with a hard-wired tty
line).

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!

The reason this is such a generic issue of computing systems scurity of
course is that a fundamental requirement, or perhaps it's better called
an assumption or even axiom, of such good computing systems security is
there must be a direct correspondence between system identities and real
people.  This initially presents a quandry in the case of a generic
system identity, which by definition might be authorised for use by
several individuals.  In the case where that identity has special or
supreme system privileges, the quandry must be solved because it is
critically important to provide a concrete audit trail to link the
actions made while a person is authenticated and authorised as that
generic privilged system identity with the real person performing those
actions.  When a system further allows the use of basic simple multi-use
passwords for authentication the importance of such an audit trail is
nearly astronomical in poroportion!

The idea behind the "secure" flag in /etc/ttys is of course to makes it
possible to restrict authorised users to only using terminals which
might be in a secure location where there might be an audit trail kept
of their access to the location (eg. a sign-in log, or an electronically
recorded pass card, etc.) when they login as the generic, but supremely
privileged, "root" user.  If I'm not mistaken the "secure" flag was
specifially invented in *BSD to deal with the issue of ptys such that
root logins could implicitly be prevented on ptys which were, even in
the very beginnings of TCP/IP, known to be flatly insecure when used to
connect a network circuit to a login session.  Where a secure terminal
is not used the idea is to force authorised users to first authenticate
themselves with their own personal unique user identity an then require
them to use the "su" utility such that an audit trail is left to show
which real person accessed the generic account in a given session.

Now don't get me wrong here -- I'm not trying to pretend that NetBSD
should pretend to be 100% truly secure out-of-the-box.  We all know that
unix in general is not considered to be a very secure system, meeting C2
only in extremely special circumstances and configurations and only
certifiable in individual installations and without a network interface.
For example with "su" the audit trail is traditionally kept on the
system and should an ordinary user discover the root password they can
trivially edit the audit trail and either eliminate evidence of their
activity, or even mis-direct blame to any other user.

Note that NetBSD doesn't even yet have mandatory access controls or full
access auditing capabilities, so it can't even begin to meet even the
basic C2 security requirements.  That doesn't mean though that NetBSD
admins should simply give up on security.  There's a lot to be said for
observing good strong security policies and keeping security in the
forefront of every user's mind, and especially in the forefront of the
system manager's thoughts!

Similarly though one might make the analogy with an honor system log
book in the computer room where you're supposed to sign in and state
which system's you're going to be working on and why, etc.  This kind of
security is a deterrent -- it's not a technical control that provides
absolute security (like a personalised swipe card, or a pair of security
guards from different divisions sitting at the desk in the lobby, etc.)

> Because there is a paper presented
> at usenix which indicates that doing an su over an ssh session leaks info.
> If the password was taken from natural text, the info leaked might be on
> the order of the entropy in the password! See the paper for details.

Yeah I'm aware of it, but that's really just an example of a generic
problem with multi-use password authentication and that paper just shows
that SSH isn't really all that immune to the problem.  It's not too
surprising either (it seems to me computer people often tend to forget
the nearly thousands of years of history cryptographers have at learning
to crack through crypto systems with often the most out-of-the-blue
sideways attacks [though this one is really just a basic application of
already well known techniques]), and it's really only another nail in
the already quite tightly sealed coffin of multi-use passwords.

When I talk about multi-use passwords I'm more concerned with the fact
that two separate people might use one of them to authenticate
themselves and gain access to a generic privileged account.  It really
doesn't matter how they acquire that password, and whether or not they
have it legitimately, nor even what kind of channel or terminal they use
to initiate their session.  Indeed only in the case where there's
adequate external security (automated or manual) guarding and recording
access to a terminal marked as physically secure is it OK to allow
direct access to a generic (i.e. shared) privilged account.

Don't even get me started on how NetBSD out-of-the-box still allows a
user to choose any extremely lame password despite the availablity of
directly appliable patches to implement basic checks (corresponding to
those used by most brute-force password guessing/cracking tools) before
accepting a new password as valid!  ;-)

> You've dived into a policy decision. You are more than welcome to want to
> require that for your sites, but a number of admins have decided that
> knowing whomever acts as root is one of the root-accepted people (someone
> who is supposed to know the password), things are fine.

The issue here is what's appropriate for the generic out-of-the-box
default for NetBSD's configuration.  It seems quite clear that NetBSD
has followed the traditional requirement of necessitating direct root
logins occur only on the physical console and that users always be
strongly encouraged to always use 'su' and to not directly login as
root, even on the physical console.

The idea here is to encourage authorised administrators to always cover
their own behinds by leaving an audit trail whenever they do anything
legitimate.  When you bring SSH into this picture, given the current
implementation and the current default configuration of the daemon, this
means preventing all direct root logins via SSH too.

Like I suggested, *you* are free to re-configure /etc/ttys to allow
direct root logins on any hard-wired terminal you declare to be secure
(and under your definition of security).  *You* are also free to
reconfigure SSH to make it possible to authenticate real users by their
RSA keys, and/or to assume that your admins are smart enough to only use
SSH from sufficiently secured systems, etc.  Similarly *you* are free to
ensure that only one person knows the root password (which of course
means creating additional superuser accounts with unique passwords if
you've more than one authorised administrator).  I.e. *you* and *I* both
are just as free now as we were before to re-configure NetBSD from its
out-of-the-box defaults such that it will implement our own specific
local security policies w.r.t. direct root logins.

However if NetBSD is to maintain the same pre-SSH (implied) policy of
only allowing direct root logins on physically secure (where this only
means equally physically secure to the rest of the actual system
hardware) ttys (in the same way it also always strongly advises
authorised administrators to login as themselves and use 'su') then
NetBSD must not now allow direct root logins over SSH, especially not
with the default SSH configuration where multi-use passwords are
allowed, and explicit pre-set client host keys are not required.

(I.e. the default sshd configuration in NetBSD is really only just
barely suitable for allowing ordinary users to connect, let alone root!)

> > Yes, in specific and well controlled situations you'll be able to show
> > in an audit which real person authenticated themselves as "root" over an
> > SSH protected session.  However in general, for a default configuration,
> > this cannot be assumed, especially since the default SSH configuration
> > also permits connections to be authenticated and authorised with only a
> > multi-use password.
> 
> If you're feeling that way, then you really shouldn't be using ssh. You
> should use kerberos. One of its design features is that (unless you stay
> logged in for a long time, like over a day) you only type your password
> once, and it stays on the local machine where you first authenticate. From
> then on, you don't type your password (so you aren't vulnerable to the
> attacks in the paper I mentioned) and I think you get the logging of who
> became root that you want.

Those are entirely separate issues, mostly unrelated to what I was
trying to get at in the paragraph above yours, and the solution you
present to those new issues has many of its own problems, including use
of multiple integrated servers with very stringent requirements for
physical security, etc.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>