On Sun, 2 Sep 2001, Bill Studenmund wrote:

> No, we permitted root logins from "secure" ttys. Physical access was not
> listed as the deciding factor. Yes, physical access is an obvious example
> of a "secure" terminal, but it is not, from what I've seen, the
> definition.

We mark the console secure and all other terminals not secure. On all
but a very few of our ports, this corresponds to physical access versus
not for the vast majority of configurations.

> The whole point of the thread is that in a number of people's eyes, it is
> possible to have secure, remote connections.

Sure. I'm not disagreeing with that. What's I'm disagreeing with is:

> ...object to you deciding that your take on things is the one true way, and
> is more important that many years of common practice, both with NetBSD and
> most all of the ssh installed base.

What do you mean, "with NetBSD"? How, before we started shipping ssh,
could you get to root from a non-secure terminal with only the root
password?

Answer: you couldn't. (Unless maybe you exploited a security hole.)

So "years of common practice with NetBSD" were broken when we started
shipping ssh.

It also seems to me that NetBSD has more recently been taking the the
"need knowlege to make it less secure" rather than the "need knowledge
to make it more secure" approach, and this new default fits in with that.

> > >	if there's any buffer overrun or other
> > > 	vulnerability, root privilege will get compromized anyways regardless
> > > 	from PermitRootLogin.  what kind of middle ground are you aiming for?
> >
> > Please re-read my commit message carefully, as well as the various
> > messages here to see what the security policy was (and now is again),
> > exactly.
>
> Please do not be condescending.  I understand what your point is....

No, from the paragraph above, you do not seem to understand my point.

Root being compromised by buffer overruns or similar vulnerabilities has
no relation to this change. No relation whatsoever. And you understand
this. So why do you even bring it up? And what' sthe point of the
following question? I'm not aiming for any middle ground, I'm aiming
to implement a specific security policy that i describe in the commit
message.

I'm sorry if I sounded condescending, but this whole issue is getting
really old for me, because people keep raising things not relevant to
this change.

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 3 5778 0123   http://www.netbsd.org
    Don't you know, in this new Dark Age, we're all light.  --XTC