/dev/random vs. /dev/urandom and the krb5 test suite
epeisach at MIT.EDU
Thu Jun 18 18:07:15 EDT 2009
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
>> 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
> 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...
More information about the krbdev