<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 06/13/2014 10:20 PM, Simo Sorce wrote: </div> <blockquote cite="mid:1402690825.22737.84.camel@willson.usersys.redhat.com" type="cite"> <pre wrap="">On Fri, 2014-06-13 at 14:29 -0400, Rob Crittenden wrote: </pre> <blockquote type="cite"> <pre wrap="">Rob Crittenden wrote: </pre> <blockquote type="cite"> <pre wrap="">Simo Sorce wrote: </pre> <blockquote type="cite"> <pre wrap="">On Wed, 2014-06-11 at 17:03 -0400, Rob Crittenden wrote: </pre> <blockquote type="cite"> <pre wrap="">0001 When is_allowed_to_access_attr() fails it should include the value of access in the error log for debugging. </pre> </blockquote> <pre wrap=""> Ok added more detailed logging </pre> <blockquote type="cite"> <pre wrap="">Nit: Coluld not fetch REALM backend </pre> </blockquote> <pre wrap=""> Fixed </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> 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 </pre> <blockquote type="cite"> <pre wrap="">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" </pre> </blockquote> <pre wrap=""> Ok this should be working now, I added a new ACI to allow also managedby#USERDN to operate on keytabs. New patches attached. </pre> </blockquote> <pre wrap=""> 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. </pre> </blockquote> <pre wrap=""> 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. </pre> </blockquote> <pre wrap=""> [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 ? </pre> </blockquote> 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 = <a class="moz-txt-link-rfc2396E" href="ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX">"ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX"</a>;) -dn: cn=accounts,$SUFFIX +dn: cngaccounts,$SUFFIX <blockquote cite="mid:1402690825.22737.84.camel@willson.usersys.redhat.com" type="cite"> <pre wrap=""> </pre> <fieldset class="mimeAttachmentHeader"></fieldset> <pre wrap="">_______________________________________________ Freeipa-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:Freeipa-devel@redhat.com">Freeipa-devel@redhat.com</a> <a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/freeipa-devel">https://www.redhat.com/mailman/listinfo/freeipa-devel</a></pre> </blockquote> <pre class="moz-signature" cols="72">-- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org </pre> </body> </html>