[Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs

[Petr Spacek]

On 29.5.2014 18:40, Nathaniel McCallum wrote:
> On Mon, 2013-09-23 at 08:12 -0400, Simo Sorce wrote:
>> On Mon, 2013-09-23 at 09:00 +0200, Petr Spacek wrote:
>>> On 20.9.2013 21:35, Simo Sorce wrote:
>>>> This patch set is an initial implementation of ticket #3859
>>>>
>>>> It seem to be working fine in my initial testing but I have not yet
>>>> tested all cases.
>>>>
>>>> However I wonted to throw it on the list to get some initial feedback
>>>> about the choices I made wrt access control and ipa-getkeytab flags and
>>>> default behavior.
>>>>
>>>> In particular, the current patch set would require us to make
>>>> host/service keytabs readable by the requesting party (whoever that is,
>>>> admin or host itself) in order to allow it to get back the actual
>>>> keytab. I am not sure this is ideal. Also write access to the keytab is
>>>> still all is needed to allow someone to change it.
>>>>
>>>> Neither is ideal, but it was simpler as a first implementation. In
>>>> particular I think we should allow either permission indipendently, and
>>>> it should be something an admin can change. However I do not like
>>>> allowing normal writes or reads to these attributes, mostly because w/o
>>>> access to the master key nobody can really make sense of actually
>>>> reading out the contents of KrbPrincipalKey or could write a blob that
>>>> can be successfully decrypted.
>>>>
>>>> So I was wondering if we might want to prevent both reading and writing
>>>> via LDAP (except via extended operations) and instead use another method
>>>> to determine access patterns.
>>>>
>>>> As for ipa-getkeytab is everyone ok with tryin the new method first and
>>>> always falling back to the old one (if a password has been provided) ?
>>>>
>>>> Simo.
>>>
>>> I was always curious why we don't use normal kadmin protocol? :-)
>>
>> Kadmin won't respect LDAP based ACIs, it always operate as "root"
>> against LDAP,
This leads to question: Why? Wouldn't be approach with S4U sufficient?

 >> and has it's own simple ACL file. We want to be able to
>> easily manage and delegate access to keytab creation.
>>
>> We might try to change the kadmin code to impersonate the user but I
>> think it would be invasive, I never seriously looked into it though.

IMHO we have two options:
A) Operate as root & use LDAP proxy control.
-- Determine DN of an object representing principal used by user.
-- Use LDAP proxy control with given DN.

B) Use S4U and connect to LDAP with user's credentials.

> Wouldn't such an approach have inherently better security properties
> (and potentially gain other operations for free)? The current patch set
> is also invasive (at least in terms of its size). If the kadmin approach
> is a similar sized or smaller change, I'd probably prefer that.

I agree with Nathaniel.

-- 
Petr^2 Spacek