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

[Russ Allbery]

Tom Yu <tlyu at MIT.EDU> writes:

> I'm leaning toward checking an environment variable inside these two
> programs.
>
> * Environment variables tend to have a checkered security history,
>   like Sam says.
>
> * Checking an environment variable is far easier to implement.

If checking an environment variable is far easier to implement than
adding a configuration option to an existing configuration file, I think
that indicates there's something seriously wrong with your configuration
management API.  This should not be the case.

> * If we implement by checking an environment variable in these two
>   programs to determine whether to read strong random numbers, it
>   localizes the risk to an administrator running the command while
>   having a specific environment variable set.  IMHO, administrators
>   should take care to keep their environment clean, especially while
>   performing security-critical operations.

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 Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>