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

[Tomas Babej]

On 06/13/2014 10:20 PM, Simo Sorce wrote:
> On Fri, 2014-06-13 at 14:29 -0400, Rob Crittenden wrote:
>> Rob Crittenden wrote:
>>> Simo Sorce wrote:
>>>> On Wed, 2014-06-11 at 17:03 -0400, Rob Crittenden wrote:
>>>>> 0001
>>>>>
>>>>> When is_allowed_to_access_attr() fails it should include the value of
>>>>> access in the error log for debugging.
>>>> Ok added more detailed logging
>>>>
>>>>> Nit: Coluld not fetch REALM backend
>>>> Fixed
>>>>
>>>>> There are still a ton of "ber_scanf failed" duplicated fatal errors. I'm
>>>>> fine keeping a common err_msg but the fatal error should be unique.
>>>> Yeah thanks to this comment, I had a small change of heart.
>>>> Instead of sending such detailed information to clients I reverted to
>>>> send a little less information to the clients and instead LOG_FATAL in a
>>>> more detailed way. HTH
>>>>
>>>>> This breaks normal host delegation. If you add a host to another host's
>>>>> managedby, getting the keytab will fail. This is due to:
>>>>>
>>>>> [11/Jun/2014:16:56:45 -0400] NSACLPlugin - conn=4 op=3 (main): Deny
>>>>> write on
>>>>> entry(fqdn=client2.example.com,cn=computers,cn=accounts,dc=example,dc=com).attr(ipaProtectedOperation;write_keys)
>>>>> to fqdn=client1.example.com,cn=computers,cn=accounts,dc=example,dc=com:
>>>>> no aci matched the subject by aci(97): aciname= "Groups allowed to
>>>>> create keytab keys", acidn="cn=accounts,dc=example,dc=com"
>>>> Ok this should be working now, I added a new ACI to allow also
>>>> managedby#USERDN to operate on keytabs.
>>>>
>>>> New patches attached.
>>> Functionally these seem to work ok. I think there should be some
>>> documented way to enable the -r in ipa-getkeytab. Right now I'm not even
>>> entirely sure how one would add a permission to do so.
>> NACK
>>
>> Simo noticed that the ACIs are in cn=accounts. On the one hand this is a
>> reasonable place to put these, on the other it is a bit broad.
>>
>> I think we'll need type-specific ACIs in a number of subtrees: users,
>> computers and services.
> [Only patch 3 attached, as none of the others changed, and addiotional
> discussion is needed, see below.]
>
> Ok after looking carefully into this problem I see that there are really
> 2 issues.
> 1) managedby for users, we do not want someone adding a managedby
> attribute to inadvertently allow the manager to set a user's password.
>
> So I changed that ACI and restricted it only to ipaHost and ipaService
> objects (tested).
>
> I haven't touched any other ACI because in order to use them you need to
> have intentionally added an ipaAllowedToPerform attribute to the user
> entry.
>
> 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 ?
>
> Otherwise we can add ipaProtectedOperation in the exclude list for the
> superACI ("Admins can manage any entry") and add the following ACI in
> cn=accounts, to restore admin ability to set keys (but not retrieve
> them):
>
> 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 tested this combination and it effectively stops admin from retrieving
> all keys unless explicitly authorize by positive
> ACIs/ipaAllowedToPerform attributes.
>
>
> Thoughts ?

Just a heads up, I managed to catch a typo with my sleepy eyes:

--- a/install/share/default-aci.ldif
+++ b/install/share/default-aci.ldif
@@ -21,11 +21,17 @@ changetype: modify
 add: aci
 aci: (targetfilter =
"(|(objectClass=ipaConfigObject)(dnahostname=*))")(version 3.0;acl
"Admins can change GUI config"; allow (delete) groupdn =
"ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";)
 
-dn: cn=accounts,$SUFFIX
+dn: cngaccounts,$SUFFIX


>
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel

-- 
Tomas Babej
Associate Software Engineer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140613/2d7a5a23/attachment.htm>