On Tue, 4 Sep 2001, Bill Studenmund wrote:

> If you were focusing on having a
> log of who became root, then it is a valid arguement (and some folks in
> this thread are).

I am not. What attacks others bring up, and how this might relate (or
might not relate) to my commit are really not under my control.

Probably it would be a good idea to start a separate thread for anything
you want to argue about that's not directly related to my commit.

> > 1. This security measure is intended as a defense aginst people I've
> > NOT given the password to.
>
> Ahhh... Ok. But how much of a defense is it? _HOW_ is it a defense?

From the commit message:

    ...if you are not on a secure terminal, you must be able to
    authenticate as a user in the "wheel" group before you may attempt
    to authenticate as root using the root password.

So the defense is that, though you have the root password, you must also
either gain access to a secure terminal, or authenticate as a user in
the wheel group.

> > > As for the, "it's now two passwords to crack," arguement, I don't think
> > > that buys you much. Theo, in private communications, pointed out a paper
> > > presented at usenix (that I admit I haven't read) which idicates that you
> > > can snoop ssh trafic and see when someone is doing an su, and how long a
> > > password s/he typed. So if you're in the cracking mood, you find who does
> > > sus, attack such a person's account, and install a snooper.
> >
> > Right. And this is just as easy as "ssh foo" followed by typing the
> > password? No, I don't think so.
>
> What does that mean?

Just what I said. Typing "ssh root@somehost" and typing a known password
is much, much easier than installing a sniffer, attacking the account
of a user with a reasonably secure password (or no password!), or many
other things.

You could conceivably convince me to change my mind on this issue by
presenting me with some packets sniffed from a session between me and
my mail machine (academic.cynic.net). :-)

> Please read the paper. It's at
> http://paris.cs.berkeley.edu/~dawnsong/papers/ssh-timing.pdf Logging into
> a box and then doing an su is readily noticable by a passive packet
> sniffer. Passivly watching the exchange, the snooper can get enough info
> to reduce the difficulty of brute-force hacking by a factor of 50. That's
> almost two orders of magnitude.

I'm familiar with this. And it certainly seems to reinforce my argument
that you want "PermitRootLogin = no" if administrative circumstances
permit it. In fact, this kind of attack (where someone gains the root
password) is *exactly* what I'm defending against.

> I think the
> thrust of this thread is that we disagree as to whether or not this change
> is a net win or loss in the tradeoff.

Well, I think we both agree that whether it's a net win or loss depends on
the administrative environment, which is different for every site. This
is why we tend to ship things in the "more secure" configuration or,
failing that, the "fails more obviously" configuration, and let local
admins make things less secure, or fix the obvious failure, if their
administrative environment requires it.

I think it's moderately obvious that having "PermitRootLogin = no"
defends against some circumstances that "PermitRootLogin = yes" does not,
and the converse is not true. So this is more secure.

The failure mode where the default is "no" is that you can't log in. This
is an obvious failure mode (if you need it to be "yes"), and easily
remedied by the admin. The failure mode where the default is "yes" is
that an someone (you or an attacker) with the root password can log in
directly. If this is something you don't permit as a matter of policy,
you may not be trying it, and thus may not notice the failure. So we've
also picked the much more obvious failure mode.

So it seems to me that we've got a much better default here.

If you're not arguing that we change the default that NetBSD ships
with, but simply that there are circumstances where a site would want
"PermitRootLogin = yes", well, we're in perfect agreement there.

> How likely is this scenario? How would such a person get the root password
> and nothing else? Other than say using an herbivore-type program and
> watching an su? :-)

There are lots of ways to get the root password:

    1. Shoulder-surf.

    2. Find or steal a written copy.

    3. Bribe/blackmail/whatever someone who knows it.

    4. Sniff an su over ssh on a machine where "PermitRootLogins = yes"
    (Having the option enabled doesn't stop people from running "su"!)
    and find some way to test it out. (Even with a list of potential
    passwords, you need some way to determine which one is the correct
    one, and with "PermitRootLogin = no" you can't try logging in to do so.

    5. Have had it legitimately at one point, but no longer have (or
    never have had) an account on particular machines.

Certainly for situation #5, I could reel off a dozen circumstances where
this is currently the case. (I won't, for obvious reasons.)

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 3 5778 0123   http://www.netbsd.org
    Don't you know, in this new Dark Age, we're all light.  --XTC