On Thu, 6 Sep 2001, Bill Studenmund wrote:

> But it is related as these arguements are being used as justifications for
> the change in your commit. Even if you aren't doing the arguing, they are
> used as justification.

Well, if you could at least attack my arguments and the other arguments
in different messages, I'd appreciate it. I'm sure you can imagine how
frustrating I find it, in a message directly addressed to me, appearing
to say "we should back out the change because proposition X is true"
when I agree that proposition X is true, and never considered it a reason
for the change in the first place.

> > 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.
>
> The whole point I'm arguing, is *why* is this important? *Why* do you
> think this is a more likely an attack than the attack modes opened up by
> this change?

Uh...what new attacks have been opened up by this change?

Certainly not your ssh su attack. It was possible to ssh in as a user
and su even with PermitRootLogin set to "yes". The only difference was
that in that cirumstance you could actually *use* the root password
immediately, whereas with the new default you can't.

> The point of the paper is that you can watch an ssh session and have a
> good idea when someone is interactivly typing a password. Doing an su
> involves an interactive password. Initiating an ssh root@foo connection
> does not (since your local ssh program waits for you to finish typing the
> password before sending it).

Right. I completely agree. And you know what? The setting of
PermitRootLogin DOES NOT MATTER! The attack works in both cirumstances!

Or are you proposing that we also ship NetBSD with the su command
disabled?

Anyway, again, with the new default settings, the leak does not instantly
compromise your system.

> So how is forcing folks into the more information-leking scenario good?

First of all, can we stop with the "forcing" thing? Nobody's forcing
anybody to use the default settings; they can be easily changed on
install. But let's look at the failure modes here:

Anybody whose security policy is such that they're not using
the information-leaking scenario will find out instantly that the
PermitRootLogin setting is wrong, and be able to fix it right away. This
does not compromise their security policy.

On the other hand, ironically enough, I just discovered yesterday that
a machine I reinstalled (due to a disk failure) two weeks ago did not
get the correct setting of this option, and thus my security policy has
been compromised for two weeks, in a not easily noticable manner.

> > There are lots of ways to get the root password:
>
> Note: you're assuming getting the root password and NOT getting the
> password of someone in the wheel group. That's the ONLY case you're
> defending against.

Correct.

> >     1. Shoulder-surf.
>
> And if you can shoulder-surf root's password, why can't you shoulder-surf
> the person's login?

Oh, don't be silly here. Because you didn't happen to be around when
they typed their own password, that's why.

Again, you're coming up with situations where you have to add an
additional compromise to get root. And that's my whole point: you need
to add an additional compromise.

> >     2. Find or steal a written copy.
>
> This one I can see, but it's more indicative of picking a password that
> folks can't remember. Also, aren't you not supposed to write passwords
> down?? :-)

Of course you're not supposed to write passwords down. Yet people
do. (Especially when you're changing it every time an admin leaves a large
company.) And of course you're supposed to pick passwords that people
can remember. But everybody finds different things easy to remember.
If your security policy is not going to take into account these sorts
of human failures, it's not going to be so effective.

> >     3. Bribe/blackmail/whatever someone who knows it.
>
> And the reason that you don't get that person's password is......

He no longer has an account.

> >     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.
>
> This problem you can close by telling folks to not su. :-)

Yes. You can also tell folks not to do a lot of other things.

> >     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.)
>
> All the places I've been, when someone who had the root password leaves,
> we change the root password. I really don't understand why you wouldn't.

No, you don't understand why these folks wouldn't.  But these people are
not idiots and they've decided on a reasonable (for them) cost-benefit
trade-off for their security policy.

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