Patch to ignore service principals when accepting connexions.
hartmans at painless-security.com
Wed Aug 25 19:47:37 EDT 2010
>>>>> "Roland" == Roland C Dowdeswell <elric at imrryr.org> writes:
>> In general, if an
>> application is going to use GSS_C_NO_CREDENTIAL, it needs to examine the
>> service name that was accepted and make an authorization decision.
Roland> I do not believe that there is an authorisation decision here at
Roland> all in the normal case. The client needs to ensure that it is
Roland> talking to the correct service principal but the server generally
Roland> just needs to ensure that it is talking to the correct client.
Roland> The service principal that the client selects is an issue of
Roland> configuration not of authorisation. Granted, system admins could
Roland> put inappropriate keys in their keytabs but this is not really an
Roland> authorisation problem---it is a security problem with their
I think we disagree here.
It's common for both nfs and ssh to run as root and thus it would be
reasonable to store both keys in root's keytab.
However it is not desirable for an authenticator to be reused from NFS
Something in the system needs to confirm that this is not happening.
Differences in application protocols, replay caches, etc can create
related protocol attacks. In cases where a machine has identities in
multiple realms there can be significant authorization issues.
So, I am quite certain there are authorization issues.
You can claim that these authorization issues are best handled by
managing the keytab, and that's certainly a position to consider.
>> We introduced a behavior change in 1.7 so that application no longer
>> examine the service name encoded in a ticket; instead, they look at
>> whether the key matches. This means that you can have KDC-side aliases
>> either by setting principals to have the same key or by using actual
>> aliases (as we support with the LDAP backend). In that environment, you
>> would have one key in your keytab, but the KDC would issue tickets with
>> that key for multiple principal names. The KDC configuration is the
>> layer at which authorization happens;any name that has the key in the
>> service keytab is authorized.
Roland> I think that this is aimed at solving a different problem than the
Roland> one that we have.
As someone involved in the design of that change, I believethat the type
of problem you have is well within the scope of what we were looking at.
We may not have created the facilities you need in order to take useful
advantage of that change yet--it may not be sufficiently easy from an
operational standpoint. However I think it's fair for us to look into
whether that's true and to consider options that involve making that
easier to deploy as well as alternatives like your patch.
I'd definitely appreciate your help in that.
More information about the krbdev