/dev/random vs. /dev/urandom and the krb5 test suite

[Russ Allbery]

Simo Sorce <ssorce at redhat.com> writes:
> On Thu, 2009-06-18 at 12:33 -0700, Russ Allbery wrote:

>> Given all the problems that MIT Kerberos has had with causing
>> security bugs in other packages due to the handling of KRB5_CONFIG, I
>> think this is a bad decision and a bad set of assumptions.  It's
>> easier than it might look for a person's environment variables to
>> leak.  It's rather plausible, for example, for someone to set such an
>> environment variable for testing, forget about it, su and do an
>> aptitude upgrade, and end up restarting inetd with that environment
>> variable set, at which point it can then get inherited by other login
>> sessions.

> Russ, I think that if you set a test environment variable as root and
> on a production KDC machine, and then go on a perform maintenance task
> from the same shell, then there is something very wrong in your
> procedures.

I agree.  But security is about defense in depth.

MIT Kerberos has been very bad at providing robustness around
environment variables in the past.  Many people have been burned by
this.  Having environment variables change features of code is widely
considered to be a horrible interface decision for anything affecting
security due to the way environment variables spread promiscuously.
It's roundly ridiculed in security fora.  I would really hate to see MIT
Kerberos add yet another place where magic environment variables change
the code behavior.

> The env variable would probably be set just by scripts that run the
> tests (it would not inherit as you don't set it in your shell) in any
> normal case, and will avoid creating special krb5.conf files or to
> change the system config file where the option may persist for a long
> time across reboots and restarts.

For the test suite purpose, it shouldn't make any difference whether you
use an environment variable or a configuration option, since the test
suite presumably uses its own configuration files.  Not adding an
environment variable means one fewer potential landmine affecting people
who *aren't* running the test suite.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>