[OpenAFS-devel] Re: OpenSSH, OpenAFS, Heimdal Kerberos and MIT Kerberos

[Ben Lindstrom]

On Mon, 2 Feb 2004, Dean Anderson wrote:

> On Tue, 3 Feb 2004, Damien Miller wrote:
>
> > On Mon, 2 Feb 2004, Dean Anderson wrote:
> >
> > > This doesn't mean the privsep prevented an exploit. If it segfaulted, a
> > > little more fuzzing can get shell code to run.  After that, you have at
> > > least non-root access, and you have sockets to the privsep processes that
> > > have root privilege.
> > >
> > > We know how to escalate non-root processes to root.
> > >
> > > So, the privsep didn't protect anything.
> >
> > Get real.
> >
> > My deadbolt door locks don't stop thieves who smash windows, by your
> > logic they "don't protect anything" either.
>
> That wasn't my logic, but it makes no sense to put a deadbolt lock in a
> glass door.  Nor will adding a second glass door improve your security.
>
> Basically, privsep is a second glass door.  You have to exploit the
> non-privileged part, and then you have a choice to either exploit the
> privileged part, or use another method to escalate to root.  No security
> improvement, just a gratuitous change that will break old exploit code
> that assumed it had root right away.
>

Are we basing this on facts or just handwaving?  I've seen better
arguments against Privsep from the local cracking community which has
shown proof that a kernel flaw can still be used in the unprived child.

Best you've done is make an offhanded comment with nothing to back it up.

Which shows me the cracking community have a better clue on this topic
than you do.

> > There is a world of difference between a break in a process running with
> > root privileges and a break in an unprivileged, chrooted process. It seems
> > that this value is self-evident to everyone but you.
>
> First, this is a loose, general principle. Sure, it is a good idea to
> remove privileges when a process doesn't need root privileges.  But, the
> process that creates new user connections does need root privileges. It is
> a fundamental rule that you can't remove privileges that are necessary.
> You seem to have seized on the idea of privilege removal and have taken it
> to the extreme, mistakenly believing that you could obtain more security
> somehow.
>

Proof?  Or handwaving?

I assume you also find "trusted computing" and advanced ACLs to be the
same "mistaken security belief".  They use the same concept.  Break the
problem down into smaller security modules and firewall each module from
each other in order to ensure a breach in one slows down the attacker.

Do note.. "SLOW DOWN".  Nothing we do besides fill a PC full of cement and
put it at the bottom of the deepest part of the ocean will secure a
machine.

> Second, there isn't much difference between a non-root breakin and a root
> breakin. You have to react the same way to both: You don't know if they
> didn't get root, or they did and you simply haven't found evidence of a
> root breakin. Perhaps they were very good about cleaning up their root
> activity, but lazy with their non-root crack.
>

There is one difference, and from the owner's view point it is very
serious difference.  A non-root breakin limits the attack and local
deployment of snooping.  Where you may dismiss this, some of us don't.
The slow down of the attacker gives the defender a little larger window
to shut down and resecure the network in question.

Privsep takes one gaping hole and forces the attacker to find a second
or third hole (via kernel services or through the firewall separating
prived from unprived code).

> Privsep hasn't changed anything, but it added more (exploitable)
> complication. Not to mention that it broke a great many things. If the
> non-privileged openssh process is exploitable, then probably so are the
> "privsep" parts, since the lower privilege part still has sockets to the
> root parts.  You haven't changed anything, even if there weren't easy ways

Which can only be accessed (if even exposed) through a limited view unless
you can expliot the underlying communications protocol.

So it actually does change a lot.

If you have constructive comments on improving that underlying protocol
I'm sure we are all ears.

[..]
> > Anyway, you are more than welcome to make your forked version which
> > removes security features, but please stop trolling on our lists.
>
> Anyway, I didn't join your list. This discussion is from another list
> (openafs-devel), where we were discussing openssh brokenness with respect
> to obtaining afs credentials. Someone (not me) added the openssh list to
> the distribution.  I didn't expect to convince you of the wrongness of
> your ways, either--I've looked at the code enough to know there couldn't
> be any cooperation. Its not just privsep.  This is why we need a forked
> version.  Sorry.
>

Your lack of anything but handwaving has shown me that you have prejudged
Privsep and have never bothered to understand it.

I'm really sorry if you have done that.  I had misgivings about privsep
also and it took actually writing code and understanding how that puzzle
piece fits before I felt the added complexity was justified.

OpenSSH project has always been open to different views, and some nice
additions had come because of it.  However, we don't add features just to
keep up with the Jones.  Which is what a lot of people think we should.

- Ben