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

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

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.

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

> Also, the point is that it's quite backwards to argue a change as being in
> line with an unwritten, ambiguous policy. Both you and I agree it was/is
> unwritten, and the fact we disagree makes it rather clear that it was
> ambiguous. :-) To use such an arguement makes for a weak case..

Well, I cannot argue against that!  :-)

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

> The
> other is that the absense of "secure" for ptys implies that network
> connections can't be "secure". I think the latter is a great fallacy -
> marking ptys as "secure" can open up so many cans of worms that the
> absense of "secure" on them means nothing.

Well, it depends on what you mean by "secure".  At the time that flag
was invented there was no way to secure a network connection without
resorting to very special external security measures.  This was more or
less true up until very very recently (despite Steve B.'s best efforts
to show just how insecure TCP/IP connections are in the raw).

You are very correct that marking ptys as "secure" would be a
nightmarish situation.  The point was never to mark ptys as "secure"
(even though there are many sitiations where they are every bit as
"secure" as the physical console, such as when a person logged in on the
console allocates one or more for use with `screen' or some similar
tool).  Rather the point is to restrict the number of places where a
direct root login is permitted to the very minimum possible.  You'd
never mark hard-wired tty lines in a public terminal room as "secure",
though you might mark the one in the system manager's always-locked
office as "secure".

Similarly a network connected login session that has been authenticated
and authorised using a multi-use password for a generic ID is also not,
by definition, "secure" no matter how robust the network protocol in use
might be and how secure the remote client host might be.  You simply
literally cannot have secure access to a generic account without having
some way to identify the real-life person who initiated the session
since there's absolutely no way to know who typed that password (and in
many cases with network connections not even any way to know where they
were physically at the time!).

There is very little, and maybe even no, security if there's no audit
trail linking an authentication with a real-life external person.
Systems security is not an end in and of itself.  Systems security a
means to relate control over internal data and processes to real-world
external security requirements so that representations of information
and actions within the system can have the same level of
confidentiality, privacy, integrity, and reliability as they would if
they were managed out in the real world by real people using with
physical representations (eg. with pens, paper, file folders, desks,
cabinets, rooms, vaults, buildings, security guards, etc., etc., etc.).

You might not be using multi-use passwords to remotely login via SSH as
root, but that's by default the way NetBSD worked prior to Curt's change
and before that change NetBSD's default sshd configuration was clearly
not "secure by default".

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