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

[Ezra Peisach]

Russ Allbery wrote:
> 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.
>
>   
Instead of an environment variable - how about a command line option... 
No ambiguity there, no fear of strange environment variables....  Then 
you simply need to document it... If an admin starts the program w/ such 
a feature - they deserve what they get... Also - you can then syslog in 
big letters - the fact that they enabled this...

Ezra