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

[Simo Sorce]

On Tue, 2014-06-17 at 15:49 -0400, Rob Crittenden wrote:
> 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

Ok attached corrected patch to remove the embarrassing wrong suffix.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-keytab-Add-new-extended-operation-to-get-a-keytab.patch
Type: text/x-patch
Size: 32150 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140617/342e0497/attachment.bin>