[ On Saturday, September 8, 2001 at 16:08:08 (+0100), James Ponder wrote: ]
> Subject: Re: sshd Change: PermitRootLogin = no
>
> If I attacked your mail client, my buffer overrun code might have installed
> a listening port waiting for commands or somesuch that would not be logged
> as a login event (e.g. a la code red).

Much harder to do in my specific case, but I see your point!  ;-)

(which reminds me:  "Never read mail as root!!!!!, not even with 'less'!!!")

> > It also wouldn't take me very long to learn to make religious use of a
> > "trusted path" kind of feature in SSH or similar before using 'su'....
> > (eg. and I could implement such a thing without very much effort by
> > putting a few simple hacks in all the sshd servers and slogin clients I
> > use)
> 
> Well, the only way this could really work is if you disable all profiles
> for your wheel accounts because as soon as something is run or sourced a
> trojan shell could be exec'd - the trojan shell can then record all
> keypresses and perhaps even look out for vi/more access on the tampered
> files.

I think you misunderstand what I was getting at -- my idea of what a
"trusted path" for sshd would be implicitly bypasses all those issues by
providing a clean environment to something the equivalent of
system("/bin/su -l root"), invoked directly from sshd itself.  That way
there should be no possibility of the user's personal profiles, etc.
getting in the way, so to speak.  The only weak link will still be the
ssh client host.

>  However, I'm not really thinking about what you or I do, but rather
> what the masses do - a security expert can modify a system to be as secure
> as they want - but the general masses just use what they believe they
> are supposed to,

But the masses are not generally speaking system managers....  I would
expect any competent system manager, at least of any important system,
to have some understanding of systems security issues and at least be
aware of their system's security.

> and there lies my problem, disabling root logins via ssh
> means the only way under netbsd to login as root to a box is by going through
> a user account and I don't think users are sufficiently knowledgable in
> general to use their wheel user accounts in a safe way.

I think you're too pessemistic!  ;-)  Even for a security person!  ;-)

You're also ignoring the other very real, and primary, issues of
accountability w.r.t. allowing direct root logins.  Such might be fine
for personal machines with one owner and one person knowing the root
password, but NetBSD's default out-of-the-box configuration must not
make such an assumption.  Direct root logins from remote network hosts
cannot, by definition, be secure if the authentication method is a
multi-use password, no matter how secure the network connection.

The other very real problem with the likes of SSH is that it still
requires that the client host be maintained equally securely as the
servers it's used to connect to.  A Trojan SSH client is in some ways
much easier for an attacker to deploy than any amount of trickery on the
target host, especially if the goal of using SSH is to provide roaming
access from any random client.

> Again, my perspective in this conversation is that the majority of unix
> users these days are not knowledgable enough to realise the impact of
> their actions when it comes to typing a command such as "su", and that
> the change to deny remote root logins over ssh is just going to encourage
> this bad practice (IMHO).  There may be occasions where su is completely
> safe and does increase security but I think these are few and far between.

Once again, the problem isn't that "su" is unsafe (and it's actually a
bit safer than you're making it out to be), but rather that direct root
logins have no accountability, and thus no security, in the "general"
case.

If you were to argue for requiring personal certificates to authenticate
as "root" then that would be much more acceptable.  However with the
current status of multi-use passwords being allowed (by default) for
root's authentication there's no question that forcing the continued use
of "su" is the best of two poor alternatives, at least for the generic
default out-of-the-box configuration.

> I think perhaps you've hit the nail on the head.  I think I hate su :-)
> I think su should be removed and an alternative found.  I think ssh can be
> this alternative.  There, I said it!

Yes, sshd could be the alternative to su, but that does mandate removing
'su', or at least making it impossible to use if the session is on a pty
allocated by a network attached daemon (i.e. no 'su' unless your tty is
marked "secure" in /etc/ttys!).  It also mandates the removal of
multi-use password as a potential authentication method, at least for
'root', and probably for every such potentially shared account.

The problem here is still one of choosing the best default for NetBSD
out-of-the-box though.  'su' is perfectly fine on hard-wired "secure"
terminals (assuming external physical security of the terminal and the
wire is at least as good as the security of the physical machine
itself, such as the physical console usually is ;-).

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