RFE: Portable OpenSSH

[Damien Miller]

On Tue, 27 Mar 2001, Dan Kaminsky wrote:

> Damien--
>
>     *time to trot out the grizzled-veteran-of-the-ssh-wars stories*
>
>     Here's da scoop.  So we put out a package of OpenSSH 2.2.0p1 a while
> back that required a Perl2Exe'd package of EGD.  Got adopted by about five
> people.  Turns out that the more system-level dependencies you put on
> software, the less likely people are going to be willing or able to install
> it.

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

>     Kernelspace is the place where random number generation should
> live--period.  However, should kernelspace randomness fail to exist,
> mandating the use of a pseudo-kernelspace emulation layer with prngd
> forces userspace binary dependencies.  As is, all ssh binaries
> are independent, i.e. sshd does not require ssh does not require
> ssh-keygen.  At the points where semi-dependencies exist--scp and
> sftp-server from sshd--we see the greatest occurance of SSH failure
> and annoyance.  But when scp and sftp-server don't exist, you can't
> conveniently transfer files.  When prngd wouldn't exist, however,
> you wouldn't be able to do *anything*.  No SSHD, no SSH, no nothing.

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.

>     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.

> 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.

>     Granted, this starts getting ridiculous, but my point is
> that setting up convoluted and non-obvious dependancies in SSH
> is something to avoid.  I *like* the idea of prngd, actually--I
> just don't like the idea of SSH utilities failing to function
> without it.  Lets be flexible here--*in runtime*, check for
> /dev/random(kernelspace), failing that check for a central prngd
> daemon(root kernelspace emulation), failing that check for a
> userspace prngd daemon we can run for a few minutes until it builds
> up n bits of entropy(user kernelspace emulation)...

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

>     And if all else fails, just do the damn commands yourself.
> Don't go load a list of commands from somewhere in ETCDIR, though
> grab that list if you can find it--have a list of commands that work
> on this platform compiled into an array in the binary and go through
> them.

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.

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

-d

-- 
| Damien Miller <djm at mindrot.org> \ ``E-mail attachments are the poor man's
| http://www.mindrot.org          /   distributed filesystem'' - Dan Geer