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

[Rob Crittenden]

Simo Sorce wrote:
> On Tue, 2014-06-17 at 15:30 -0400, Rob Crittenden wrote:
>> Simo Sorce wrote:
>>> On Mon, 2014-06-16 at 09:53 +0200, Petr Viktorin wrote:
>>>> On 06/13/2014 10:20 PM, Simo Sorce wrote:
>>>> [...]
>>>>> 2) and I think this is a MUCH bigger issue, the Admin users are
>>>>> unbounded and pass any Access Control Check and this means they can now
>>>>> retrieve any key for users or machines.
>>>>> It is already bad enough that admins can unconditionally set any key,
>>>>> but this at least leaves back a pretty big trail (the original client
>>>>> password/key fails to work), and is a necessary evil (password resets,
>>>>> hosts creation/recovery).
>>>>> But I am not very comfortable with the idea an admin can retrieve any
>>>>> key without actually ending up changing it. Petr do we have any short
>>>>> term plan to address the Admin's super ACI ?
>>>>
>>>> No, nothing in the short term.
>>>
>>> Ok, then I think attached is the patch 0003 we want.
>>> This changes admins superpowers to not allow ipaProtectedOperation by
>>> default and instead adds a specific right in cn=accounts so admin can
>>> keep fetching keytabs for any principal. We may want to turn this into a
>>> permission with a future patch.
>>
>> Upgrade in F-20 fails:
>>
>> Upgrade failed with ACL Syntax
>> Error(-5):(targetattr=\22ipaProtectedOperation;write_keys\22)(version
>> 3.0; acl \22Admins are allowed to rekey any entity\22; allow(write)
>> groupdn = \22ldap:///cn=admins: Invalid syntax.
>> IPA upgrade failed.
>>
>> You also have $SUFFIX hardcoded as dc=ipa,dc=dev,dc=lan here and in
>> default-aci.ldif . I think the fix is to quote the whole thing like:
> 
> Arghh :(
> Let me fix that, sorry.
> 
>> -add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0;
>> acl "Admins are allowed to rekey any entity"; allow(write) groupdn =
>> "ldap:///cn=admins,cn=groups,cn=accounts,dc=ipa,dc=dev,dc=lan";)
>> +add:aci: '(targetattr="ipaProtectedOperation;write_keys")(version 3.0;
>> acl "Admins are allowed to rekey any entity"; allow(write) groupdn =
>> "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";)'
>>
>> I don't know if this is your issue or not, but after fixing that the
>> upgrade still fails with:
>>
>> Upgrade failed with unknown object class "ipaVirtualOperation":
> 
> I know nothing about this. I do not touch or manipulate this in any way.

Ok, I guess we'll need someone to take a look at that, maybe it's a
generic 4.0 upgrade issue.

> 
>> 2014-06-17T19:17:20Z DEBUG Final value after applying updates
>> 2014-06-17T19:17:20Z DEBUG dn: cn=request certificate,cn=virtual
>> operations,cn=etc,dc=greyoak,dc=com
>> 2014-06-17T19:17:20Z DEBUG objectClass:
>> 2014-06-17T19:17:20Z DEBUG      nsContainer
>> 2014-06-17T19:17:20Z DEBUG      top
>> 2014-06-17T19:17:20Z DEBUG      ipaVirtualOperation
>> 2014-06-17T19:17:20Z DEBUG cn:
>> 2014-06-17T19:17:20Z DEBUG      request certificate
>> 2014-06-17T19:17:20Z DEBUG [(0, u'objectClass', ['ipaVirtualOperation'])]
>> 2014-06-17T19:17:20Z DEBUG Live 1, updated 1
>> 2014-06-17T19:17:20Z ERROR Upgrade failed with unknown object class
>> "ipaVirtualOperation"
>>
>> On update the global admin ACI is not changed to add
>> ipaProtectedOperation to the list of protected attributes.
> 
> uhmm can you show me exactly what your current ACI looks like ?

Sorry false alarm, I misread the aci output.

Functionally the patch otherwise looks ok.

rob