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

Why it seems that on some ports not even all of the virtual console
screens are marked as secure!

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

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

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.

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.

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.

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