On Tue, 4 Sep 2001, Curt Sampson wrote:

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

No, at least on macppc and i386, we mark the video console (ttyE0 etc.)
and all direct connect serial ports (tty00 through around tty07) as
secure. I don't think at any point you've tried to argue that a modem
connected to a serial port constitutes a "secure" connection. I do admit
that we don't enable the serail ports (so there would be some
configuration action before a modem on a serial port accepted logins), but
we do mark them as "secure".

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

I diagrammed the sentance differently than you did. "NetBSD" and "most all
of" go with "the ssh installed base."

Every time I've installed closed-ssh and openssh on a NetBSD system, it
has come with root login enabled. It's been the default, and I'll admit
I've been happy with that. Since like 1995 if I remember right. So that's
six years of prior experience. The AIX boses, the Ultrix boxes, and the
Solaris 2.x machines do/did the same. As far as I know, every other system
which ships openssh enables root login by default. It's an option so if
you don't want it (as you don't), you can disable it.

That's the years of common practice I'm talking about.

I think part of the problem is that there are three things in play here.
1) how we've dealt with logging in via terminals (log in as you and then
su), 2) how ssh & open ssh have handled root logins (permitting them over
a secure ssh connection), and 3) how ssh defaults when shipped with
NetBSD. The problem is that (1) and (2) disagree, so there's no way for
(3) to agree with both. I think Itojun's point was that the consequence of
making (3) not agree with (2) (our defaults are different from openssh's)
was bad. It makes us be different, for reasons which are not 100%
accepted.

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

Since I had a different common practice in mind (see above), I disagree.

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

See below. I don't really think that this change makes things more secure,
but it makes things more annoying.

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

Why? Because I don't seem to agree with it?

> 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

Oh, I think you were quoting Itojun at that point (where you said, "please
re-read"). I don't recall ever bringing up root exploits. That would
explain some confusion.

> 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

I'm sorry if my quoting helped lead to confusion.

> really old for me, because people keep raising things not relevant to
> this change.

My suggestion would be to examine what they are bringing up, and see why
they might think it was relevant.

I must say I don't see why the root password is so holy it needs to be
protected by having to come in as another user and su. Yes, I understand
the advantage of doing an su, and I do that (log in as me and su when I
need to do root stuff) even on systems which permit root to login. But I
don't think it's as sacred as this thread makes it out to be. If you can't
trust your admins enough that you are not comfortable with them being able
to directly log in as root rather than having them login as him/herself
and then su, why did you give them the root password in the first place?

As for the, "it's now two passwords to crack," arguement, I don't think
that buys you much. Theo, in private communications, pointed out a paper
presented at usenix (that I admit I haven't read) which idicates that you
can snoop ssh trafic and see when someone is doing an su, and how long a
password s/he typed. So if you're in the cracking mood, you find who does
sus, attack such a person's account, and install a snooper. Say change the
top of .login to exec a program which attaches itself to the input stream,
and then calls the shell in such a way that the wrapper won't attach
again. So you give the user what looks exactly like his/her login
environment. But you're there looking at keypresses.  When you see "\nsu
*" you start grabbing everything through the next two returns (the end of
the su line, and the password line too). You send those off to some
collection facility you have, and you look for su's to root.

So you've still only cracked one password, and you've got root. Only a
little more effort than just cracking root (you have to add the snooper I
describe, and hope/take steps so it doesn't get noticed), but it's still
just one password et voila!

I guess part of my concern is that, as reflected in my thoughts above,
this change doesn't really make things more secure. I think we were able
to keep the script kitties out as well with and w/o this change, that we
are still vulnerable to one admin doing malicious things (*), and we
haven't made it much harder for the really good crackers to get in. But we
have stepped away from a measure of utility. So little real gain, but
definite loss and incompatability with other openssh systems.

(*) For instance, how often do you review your authorized keys file? If
I'm being a naughty admin and the boss admin has made it so that we have
to su first, some time when I'm doing legit root stuff, I add a new key to
your authorized keys file and reset the m & a times so it's not obvious.
Then I log in as you using the key, and then su to root, and crack away.
Then it looks like you or at least your account was at fault. Oh, and I
remove the key & reset the a & m times when I'm done if I'm feeling really
sneaky.

Take care,

Bill