On Thu, 6 Sep 2001, Greg A. Woods wrote:

> [ On Thursday, September 6, 2001 at 13:36:52 (-0700), Bill Studenmund wrote: ]
> > Subject: re: sshd Change: PermitRootLogin = no
> >
> > No, my point is that the presence or absense of "security" in said file is
> > not the indicator of canon that you and other folks who are arguing about
> > "secure" in /etc/ttys are making it out to be.
>
> But it is!  What do you think it means?  Why do you think it was
> invented?  Do you disagree with the reasons I described?

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. As we both agree
(your comments follow later), actually setting "secure" on a pty would be
a nightmare for security. 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. 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. It's like a
politician saying that because I (or the other constituants) like "Mom and
Apple Pie" I should support his desire to do anything, be it drop bombs on
other countries or bankroll welfare leaches (trying to be equal-
opportunity with my political trigger buttons :-) .

> > They are non-standard to you. You're trying to argue the majority ground
> > w/o proving you have it.
>
> What I and others are arguing for here has been the majority view in
> Unix security circles for years now, if not decades.  We didn't invent
> it -- we just believe it to be true still today!  Most of what I've been
> saying has been a hard-fast assumption in almost all traditional
> computing systems security theory ever since multi-user systems began to
> consider security.

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.

> However what's becoming clear here is that your personal scenario with
> SSH and root logins is non-standard w.r.t. the default out-of-the-box
> NetBSD configuration.

It's also non-standard w.r.t. the openssh default. 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.

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

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.

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.

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.

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.

> > You seem to be rehashing two other arguements of this thread. One is about
> > audit trails, which Curt has said was not a reason for this change.
>
> Perhaps Curt had not said audit trails were the/a reason for this

Actually in one of his notes, he told me to stop using audit trails as a
counter arguement as it wasn't a reson for his change, and to start
another thread about it. :-)

> change.  However the reasons he did give are all implitly based on the
> premise that an audit trail is necessary to associate the superuser
> authentication with a real-life person, and by default the assumption
> must always be that a multi-use password can be used by multiple
> real-life people (regardless of how they gained knowleged of that
> password).  If you're not using multi-use passowrds (still the default
> for NetBSD out-of-the-box) then your audit trail may come from some
> other mechanism.

Take care,

Bill