RFE: Portable OpenSSH

[Dan Kaminsky]

> Most people griped about EGD's >1Mb working set and that they didn't want
> to depend on PERL daemons for security.

You tend to focus on the two-by-four sticking out of your eye before
complaining about the sliver.  Doesn't mean the sliver's not a problem; just
means you have easier things to complain about than the fact that it's a
pain to get working.

> This isn't quite true. sshd needs to fill its entropy pool at startup,
> it can then survive without PRNGd until OpenSSL deems the pool no longer
> has enough entropy.

Oh that's just splitting hairs and you know it ;-)

> >     But who would be running prngd?  Lets say every user used their
> > own entropy gatherer.  Instead of entropy gathering on demand, when
> > the ssh executables were actually being called, each user would be
> > hammering the box continually.  That's not elegant,
>
> Bingo - this is exactly what OpenSSH does at the moment.

No, it's not.  prngd goes ahead and grabs entropy in advance; openssh is
only grabbing entropy when it directly needs it.  It's slower, yes, but it's
more than fast enough for low-to-midrange use.

Come on, Damien.  No long term local daemon should be required to load a
client app.  You don't need ftpd to run ftp, you don't need run apache to
run netscape, you don't need BIND to access a web page.  Useful?  Sure!
It's *useful* to have a locally caching DNS server, especially if your
operating system is brain dead about how effectively it caches entries.
Required to hit Slashdot, though?!

> > of course, so lets presume there's only one user running prngd that
> > every user shares in the entropy of.  That user running prngd better
> > be root, unless you like the idea of SSHD getting its entropy stream
> > from an untrusted user.  So now users cannot safely run ssh without
> > the root user starting up a daemon?
>
> Well root has to run init too, so there is precedent.

What precedent?  I can log into an arbitrary box, compile my alpha
feature-loaded build of SSH on it to test for compatibility, and type:

./ssh-keygen -f tempkey
./sshd -h tempkey -f sshd_config -p 20022

> What is the advantage of all this runtime checking? Systems with
> /dev/random should _always_ have it available.

Surprised the hell outta me when I realized this was a problem.  I installed
the ANDIrand package on my dev box some time ago, then later built the
latest OpenSSH.  Imagine my surprise when the binaries compiled on that
machine wouldn't work on any other Solaris machine--oops, none of the other
ones had ANDIrand installed.

Moral of the story:  Just because this platform had /dev/random once doesn't
mean it always will--and hopefully, just because it didn't when this binary
was compiled doesn't mean it always won't.  Slowly but surely, modules will
pop up for OS's that lack /dev/random.  Rather than require a code
recompile, we can simply agree that kernel entropy will *always* be of
higher quality than user entropy and therefore we will dynamically(or at
least after a kill -HUP) switch to the better source.

Especially sites with speed problems from *both* prngd *and* ssh_prng_cmds
will appreciate this.

> No, the "hash a big list of commands" is what we want to get away from.
> I really don't like root owned or suid executables running long lists of
> system commands when it is not their business to.

Can't we safely execute external commands as irrevocable-nonroot?  I thought
the act of opening a new process granted us that ability, which we otherwise
lack when, say, opening a proprietary authentication library.

> PRNGd has been designed (and audited) to do this task well.

Like I said, I *like* the concept of prngd.  I just don't accept that a
local daemon should be required for a local client to execute successfully.
Help it out?  Speed it up?  Increase efficiency?  Decrease redundancy(as
long as the shared source is root)?  Sure.  But *mandate*, on penalty of
failure?

Yours Truly,

    Dan Kaminsky, CISSP
    http://www.doxpara.com