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.

> > 2) The model of /etc/ttys really
> > doesn't fit with network logins (secure or insecure).
>
> I agree, but that does not change the fact that as evidence of a policy
> decision it is abundantly clear that NetBSD, in general, does not, by
> default, condone root logins on anything but the physical console (or of
> course one of it's virtual, but physically identical, screens).

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.

> > We don't even mark
> > network connections (well pty's) as "on" or "off"! They don't fit the
> > model.
>
> Indeed pty's don't fit the model.  In fact they're almost always
> considered to be "remote" since from a tty's point of view there's no
> way to know if they're allocated for a local client, a connection
> terminating on an AF_LOCAL socket, or even a connection originating from
> a local LAN segment (each of which might be considered "local" and
> "secure" depending on your point of view).
>
> As someone has already mentioned it might be possible to use
> pre-allocated groups of PTYs to represent different levels of security,
> but of course none of that is possible by default in NetBSD or with SSH.
>
> > So saying that this change makes sense because pty's don't fit one
> > part of the /etc/ttys model, while pty's don't fit other parts of said
> > model, doesn't make sense.
>
> Of course not -- because all of that is moot.  The only interesting
> point here is that NetBSD does not in general condone root logins
> anywhere but on the physical console (by default).

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.

> If *you* personally feel that SSH-protected sessions are secure enough
> to be used for root logins directly then *you* personally can configure
> the machines you are responsible for in such a way to allow that.
> However in general there's every reason to not trust even SSH-protected
> remote sessions to allow direct root logins.

Why? Do you have papers indicating that ssh-protected sessions doing
direct root connections are insecure? 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.

> Let me go back over some very important concepts here, because even
> though I suspect you're quite familiar with them on their own, you seem
> to be either ignoring them or not putting them together properly in this
> case for the purposes of making a very generic default policy decision.
>
> One of the most fundamental requirements of computer security,
> regardless of whether or not networks are involved, is that there be
> some way to link an authenticated and authorised system ID to a real
> person in the real world.  In general this is not something that can be
> expected for the ID "root" since in general there will be more than one
> person who will know or have the necessary information to authenticate
> themselves to the system as this ID.  This means that in general a
> system must rely on external physical security measure to ensure that
> the actions of a person authenticated and authorised as the "root" ID
> can be traced back to a specific real person.

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.

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

Take care,

Bill