[7093] in Kerberos
Re: Problems running gss-server example as non-root
daemon@ATHENA.MIT.EDU (Sam Hartman)
Mon Apr 15 16:39:58 1996
To: Barry Jaspan <bjaspan@MIT.EDU>
Cc: edhill@strobe.weeg.uiowa.edu, kerberos@MIT.EDU
From: Sam Hartman <hartmans@MIT.EDU>
Date: 15 Apr 1996 16:21:59 -0400
In-Reply-To: Barry Jaspan's message of Mon, 15 Apr 96 12:05:17 EDT
>>>>> "Barry" == Barry Jaspan <bjaspan@MIT.EDU> writes:
Barry> Sure is. In fact, there is a convenient
Barry> environment variable that sets the default in our current
Barry> code; I believe this dates back to Beta5. Try setting
Barry> KRB5_KTNAME=FILE:/somewhewhere.
Barry> Marc and I had an argument some time ago about whether it
Barry> was a a good idea to allow an environment variable to set
Barry> the keytab, and he eventually convinced me it was a bad
Barry> idea. There have been numerous attacks in the past that
Barry> allowed an attacker to set arbitrary environment variables
Barry> for servers executing on remote machines. These holes tend
Barry> to be fixed by enumerating the set of environment variables
Barry> that should not be settable remotely. It is a good bet
Barry> that KRB5_KTNAME is not on any of those lists, so it may be
Barry> settable. An attacker could set the variable to point to a
Barry> keytab that he controls, so he would know the key and
Barry> therefore be able to break into the service.
This naturally came up when the telnet environment hole was
discovered last September. The solution at that point was to invent
an idea called a secure context, used by programs like ksu and (when
it gets krb5 support), login. In a secure context, environment
variables like KRB5_CONFIG are not checked. I just looked at the
code, and KRB5_KTNAME is only considered if the context is insecure.
Barry> I therefore suggest that the default keytab NOT be settable
Barry> by an environment variable. Changing the default should
Barry> require explicit action on the part of the program
Barry> accessing the keytab (for example, a response to a
Barry> command-line argument).
There are valid arguments on both sides, and I think we may
end up agreeing with you eventually, but I would rather discuss the
issue before making code changes.
Barry> Barry
