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 > Freeipafirstname.lastname@example.org > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org
_______________________________________________ Freeipa-devel mailing list Freeipaemail@example.com https://www.redhat.com/mailman/listinfo/freeipa-devel