[ On Thursday, September 6, 2001 at 18:03:04 (-0700), Bill Studenmund wrote: ]
> Subject: re: sshd Change: PermitRootLogin = no 
>
> The reason I do not think it means what you think it does, with respect
> for ptys, is that for it to have meaning, both its presence and its
> absence would have to convey meaning and be reasonable. 

And so the "secure" flag does carry reasonable meaning -- on any port
but a pty of course.  The issue w.r.t. ptys (at least with the default
pty allocation algorithm) is simply that they should never be marked
"secure".  But don't you remember when unix computers commonly had more
than just their consoles, two tty ports, and a bunch of ptys?  :-)

I've already given examples of where such meaning is easily found and is
quite reasonable to expect (and historically was used for exactly such
purposes!), on normal async ttys.

I even remember hacking uugetty on non-BSD boxes to include a similar
feature that would lamely prevent direct root logins on dial-up lines!

> As we both agree
> (your comments follow later), actually setting "secure" on a pty would be
> a nightmare for security.

Yes we do agree on that point.  But the reason to never put "secure" on
any pty is because the generic default pty allocation algorithm does not
utilise separate pty sets for local and network use; not because
the "secure" flag is meaningless or ill-defined.  It's ptys that are
ill-defined!  ;-)

> Doing that would be equivalent to adding
> "secure" to EVERY line in /etc/ttys. It would be a *MUCH* broader stroke
> than enabling root ssh logins. 

Yes (unless you modify the pty allocation algorithm used by sshd and by
other daemons and tools in the system such that a group of ptys is
reserved for local-only use, eg. by screen, xterm, etc. :-)

> Thus to me the only state for ptys is to
> not have "secure" on them, so the fact that they don't have "secure"  on
> them strikes me as a bad motivation for other changes.

Agreed, at least with the default pty allocation algorithm, i.e. the
same one that's used out-of-the-box for both sshd and non-network tools
such as screen (and even xterm).

That doesn't mean you can't use the "secure" flag in very meaningful
ways on other ttys though (either through its presense or its
absence)....


> Uhm, I think the people who make both commercial ssh and openssh fuss
> quite a lot about unix security. And they see value in having direct root
> logins be the default.

Ah, but the SSH and OpenSSH maintainers have very different goals and
issues to deal with than NetBSD does for their respective default
out-of-the-box configurations.

I can in fact show that the SSH developers were not really all that
savvy about various vendor and version specific Unix security features.
Indeed only in their very most recent release have they finally fixed
some features related to properly supporting password aging.  I'm not
sure yet whether they've yet fixed issues to do with platform-specific
password lockouts yet or not.  Oddly they've ignore patches I've
submitted to them about some of these issues....  Of course I wouldn't
necessarily expect SSH developers to be experts in the much wider field
of Unix systems security, and just as I don't expect them to be experts
in all the details of all the varieties of unix and unix-like systems
out there.

As for explaining why they might have thought it OK to permit direct
root logins by default, that's easy.  Such a configuration is not a
problem if you follow the advice of many security experts and always
avoid multi-use passwords if at all possible (since most other feasible
schemes will involve unique personal authentication).

Note also that NetBSD is very useful without SSH (and even without a
network!), even though both of those things are pretty much the default
for the out-of-the-box configuration.  (not that this is really relevant
to a discussion about an SSH configuration option!  ;-)


> It's also non-standard w.r.t. the openssh default.

There's no question about that, but it's not really relevant to NetBSD's
default out-of-the-box configuration.

I wouldn't be entirely surprised though if the default PermitRootLogin
setting in OpenSSH was soon flipped to "no"....  (or alternately that
their default 'PasswordAuthentication' setting might be changed -- it
already has the capability to require a non-password authentication
method for root, and that would seem to be the logical default; and even
another unique option is available to only allow public key
authentication when and if the 'command' option is also specified,
though that's maybe not as good a choice for the default setting)

> It's also non-standard
> w.r.t. what everyone has gotten by installing ssh on NetBSD before now. It
> doesn't matter if the installs were hand-rolled, or from package source -
> the default was to permit direct root logins.

I don't see how that can be relevant in any way.


The question is whether the appearance of SSH as a default feature on
NetBSD maintained the same "safe by default" security policy.

That simply cannot be true if you consider that prior to SSH the default
NetBSD configuration only ever specifyied the "secure" flag on the
physical console and related entries (for any enabled-by-default entries
in /etc/ttys), and the /root/.profile and /root/.login scripts have
always warned to use 'su' instead of direct root logins.

> > If you'd care to argue for what you're really using to become the
> > default configuration, instead of arguing against a change that's
> > apparently entirely irrelevant to you, this thread would have a much
> > different character (and no doubt outcome!).
> 
> Why do you think the change is irrelevant to me?

It would seem from your previous comments that you're running with a
somewhat customised SSH configuration.  If so then the need to customise
one more flag is irrelevant to you.  If not then I apologise for making
an incorrect assumption.

Obviously either way you still need to be made aware of the change, but
if I'm not mistaken there's already a notice prepared for the release
notes, and if indeed you merge changes from config files in a new
release I'd hope that you don't automatically accept them without
confirmation.  :-)

> My point has been that most of the reasons I've heard supporting this
> change don't add up to me. Let me recap:
> 
> 1) "It makes things more secure." Actually, it forces people into a usage
> pattern for which there is a paper describing an ssh attack, for which
> openssh has no current fix. That strikes me as a step backwards.

Preventing direct root logins in a default NetBSD configuration
definitely makes things more secure since there's no security
whatsoever, by the very definition of what systems security requires, in
allowing root logins with multi-use passwords.  (whether or not there
are multiple authorised administrators, but certainly not if there are!)

The additional risk that results from forcing people to use 'su' isn't
really that much higher with SSH -- allowing direct root logins doesn't
prevent use of 'su' so the risk is really always there regardless.  In
fact I'd go so far as to say that using the SSH 'su' attack as an excuse
for wanting direct root logins is a very poorly thought out.  Just
because one thing is potentially bad doesn't mean you should do
something that can be equally bad or worse.

The only really viable alternative to allowing 'su' over SSH is to
instead deny use of multi-use passwords (at least for root) and to
require use of some unique personal X.509-style certificate or PKI
system for authentication.  Such schemes can (if properly implemented)
eliminate the problem that there's no connection (audit trail) to point
to the real-life person authenticating as 'root', so if multi-use
passwords are outlawed by default then I would have nowhere near as much
objection to allowing direct root logins via SSH.

> 2) "It makes things more conssistent with /etc/ttys." That arguement's
> nonsensicalness I talk about above; I don't think anyone would
> sanely ever add "secure" to a pty line, thus the fact it's not there says
> nothing about ssh, just that we're sane.

See my clarifications removing the nonsense from your argument above.  :-)

Allowing direct root logins via any PTY, with a multi-use password, is
never secure because the locality of the client cannot generally be used
to identify the real-life person initiating the session.  As such it's
really irrelevant what protocol they use to initiate the session.

> 3) "It brings it in line with past policy." That policy is not written
> down. The only thing written about it, man ttys, says that "secure" means
> you can log in as root directly. It says nothing about physical access, or
> logs. It is a practical definition rather than an assesment definition. So
> there's nothing really describing that "policy." So it strikes me as a
> weak excuse.

I'd call this "written down" (from /root/.profile and /root/.login):

        echo "We recommend creating a non-root account and using su(1) for root access."

However whether this is/was an implied policy or an official written one
is really irrelevant though.  As far as I can tell "we" are not talking
about "past policy" per se, but rather the sample policy implied by the
default configuration of the system out-of-the-box in previous releases
(i.e. prior to the introduction of SSH).

There have been lots of NetBSD'ers say they want that policy to be as
"safe by default" as can be and indeed prior to the introduction of an
"integrated" sshd the default was to only allow root logins directly on
the physical console (and its virtual screens) alone.

The definition of the policy can also be found in external documentation
and folklore (you can't expect everything about NetBSD security to be
self-contained in NetBSD -- its history alone assures us that it's a
product of a much larger effort).  For example the first edition of the
"UNIX System Administration Handbook" (Nemeth et al) says:

	"Typically the secure terminals are the system console and the
	terminals housed in the personal office of people who know the
	root password."

"Essential System Administration" (Frisch) says:

	"For security reasons do not give secure status to any modem or
	PBX-switched circuit.  Network terminals also should not be
	given secure status; denying it means that anyone wanting to
	become root via a network session will need to know both a user
	account password and the root password."

Garfinkle and Spafford, in "Practical Unix Security" advise:

	"Even if your system allows you to log in directly as root, we
	recommend first logging into your own account and then using the
	su command."

I'm sure there are hundreds of similar related policy guidelines in
published and posted documents.

It seems that when you only have multi-use passwords, and especially
when there's more than one authorised person who knows the root
password, there's really only one time when it's generally considered OK
by security experts to login directly as root, and that's in an
emergency when you simply don't have time to login and su.  I suspect
the only reason direct root login is ever allowed even if only on a
"secure" terminal is that there's no really good general argument for
preventing it when the person in front of a "secure" terminal probably
has physical access to the hardware anyway, and perhaps also because
it's not a given that the root account will be a shared account.

> 4) "We want an su log." This is the one reason I've heard which strikes me
> as being on solid ground. I disagree with it, but it is a clear, direct
> desire. What I find lacking from the discussion of this reason is a
> consideration of the negatives for it: the ssh timing, where doing an su
> opens you to an attack, and the fact that we are now different from every
> other shipping (open)ssh, both those from openssh and those we "shipped"
> as part of package source.

If you want to argue against 'su' (and indeed any form of multi-use
passwords) then why don't you do that?  Certainly that would help
eliminate vulnerabilities still remaining in SSH, and no doubt it would
improve the "secure by default" position of NetBSD considerably!

Perhaps the default configs supplied in the pkgsrc modules for the
various SSH distributions should be patched to be in conformance with
the default system policy.  (Maybe I'll send-pr a patch!  Certainly I'll
provide one in the ssh3 package I'm preparing!)

As for being different from every other SSH, well, when has that ever
stopped NetBSD before?  :-)

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