[Freeipa-devel] [DRAFT2] Per-domain DNS update permissions

Wed Jun 27 12:50:34 UTC 2012

On 06/25/2012 08:50 PM, Rob Crittenden wrote:
> Simo Sorce wrote:
>> On Fri, 2012-06-22 at 14:25 +0200, Martin Kosek wrote:
>>> On 06/22/2012 02:23 PM, Simo Sorce wrote:
>>>> On Fri, 2012-06-22 at 12:20 +0200, Martin Kosek wrote:
>>>>> On 06/18/2012 05:37 PM, Rob Crittenden wrote:
>>>>>> Martin Kosek wrote:
>>>>>>> On Fri, 2012-06-15 at 10:15 -0400, Simo Sorce wrote:
>>>>>>>> On Fri, 2012-06-15 at 15:22 +0200, Martin Kosek wrote:
>>>>>>>>> Hello all,
>>>>>>>>>
>>>>>>>>> In a scope of ticket 2511 I would like to implement an ability to
>>>>>>>>> delegate a DNS update permissions to chosen user (or host) without
>>>>>>>>> having to give the user full "Update DNS Entries" privileges, i.e.
>>>>>>>>> allow
>>>>>>>>> him to modify any DNS zone or record.
>>>>>>>>>
>>>>>>>>> So far, this is what I would like to do (comments welcome):
>>>>>>>>>
>>>>>>>>> 1) Create new objectclass "idnsManagedZone" with "managedBy" attribute
>>>>>>>>> in MAY list
>>>>>>>>> 2) Create new DNS commands:
>>>>>>>>>     a] dnszone-add-managedby [--users=USERS] [--hosts=HOSTS]
>>>>>>>>>     b] dnszone-remove-managedby [--users=USERS] [--hosts=HOSTS]
>>>>>>>>>     - these commands would add/remove chosen user/host DN to managedBy
>>>>>>>>> attribute in chosen DNS zone
>>>>>>>>> 3) Add new generic ACIs to cn=dns,$SUFFIX:
>>>>>>>>> aci: (target = "ldap:///idnsname=*,cn=dns,$SUFFIX")(version 3.0;acl
>>>>>>>>> "Users and hosts can add DNS entries";allow (add) userattr =
>>>>>>>>> "parent[1].managedby#USERDN";)
>>>>>>>>> ... add similar ACIs for UPDATE, REMOVE access
>>>>>>>>>
>>>>>>>>> With these steps done, all that an administrator would need to do to
>>>>>>>>> delegate a management of a DNS zone "example.com" is to run this
>>>>>>>>> command:
>>>>>>>>> $ ipa dnszone-add-managedby example.com --users=fbar
>>>>>>>>>
>>>>>>>>> The only downside I found so far is that the user would already need to
>>>>>>>>> have "Read DNS Entries" permission assigned, otherwise he would not be
>>>>>>>>> able to actually read DNS entries (allow rules can't take precedence
>>>>>>>>> over deny rule we implemented to deny public access to DNS tree).
>>>>>>>>>
>>>>>>>>> An admin could of course create a special privilege and role with just
>>>>>>>>> "Read DNS Entries" permission and then assign it to relevant
>>>>>>>>> users/groups, but this looks awkward. Any idea to make this simpler?
>>>>>>>>> Maybe creating a group "dns readers" by default which would allow such
>>>>>>>>> access?
>>>>>>>>
>>>>>>>> Change the deny rule to deny to everyone except the user in
>>>>>>>> "parent[1].managedby#USERDN" ?
>>>>>>>>
>>>>>>>> Simo.
>>>>>>>>
>>>>>>>
>>>>>>> Good idea, I will do that. I will just use
>>>>>>> "parent[0,1].managedby#USERDN" so that user can also read the zone
>>>>>>> record. This way, a selected user will have read/write access to the
>>>>>>> chosen zone only, which is exactly what we want to achieve.
>>>>>>
>>>>>> Yes, this sounds workable to me too.
>>>>>>
>>>>>> rob
>>>>>>
>>>>>
>>>>> There were some second thoughts about the proposed design, which I would
>>>>> like to discuss so that we can eventually accept another (better)
>>>>> solution for this feature.
>>>>>
>>>>> The main concern here was that proposed solution (based on user list in
>>>>> managedBy attribute in DNS zone) is not in line with the rest of
>>>>> permission&privilege architecture in IPA.
>>>>>
>>>>> Here is another idea how to address the feature (I tested it and it
>>>>> would work):
>>>>> 1) Get rid of the deny rule on cn=dns,$SUFFIX by modifying global access
>>>>> rule (a working patch attached) to avoid current and future issues with
>>>>> extending ACIs (deny rules are evil).
>>>>>
>>>>> 2) Add new Managed Entry Definition and Template to automatically add
>>>>> "Manage DNS zone $idsname" permission. These could be used with standard
>>>>> IPA privileges, roles and thus could be assigned to users, groups,
>>>>> hosts, hostgroups...
>>>>>
>>>>> 3) New DNS zone managedBy attribute won't be manageable by user, but it
>>>>> will hold a DN of the managed Permission entry
>>>>>
>>>>> 4) Add the following ACIs to cn=dns,$SUFFIX:
>>>>> aci: (targetattr = "*")
>>>>> (version 3.0; acl "Read DNS entries"; allow (read,search,compare)
>>>>> userattr = "parent[0,1].managedby#GROUPDN";)
>>>>>
>>>>> aci: (target = "ldap:///idnsname=*,cn=dns,$SUFFIX")
>>>>> (version 3.0;acl "Add dns entries";allow (add)
>>>>> userattr = "parent[1].managedby#GROUPDN";)
>>>>>
>>>>> aci: (target = "ldap:///idnsname=*,cn=dns,$SUFFIX")
>>>>> (version 3.0;acl "Remove DNS entries";allow (delete)
>>>>> userattr = "parent[1].managedby#GROUPDN";)
>>>>>
>>>>> aci: (targetattr = "idnsname || cn || idnsallowdynupdate || dnsttl ||
>>>>> dnsclass || arecord || aaaarecord || a6record || nsrecord || cnamerecord
>>>>> || ptrrecord || srvrecord || txtrecord || mxrecord || mdrecord   ||
>>>>> hinforecord || minforecord || afsdbrecord || sigrecord || keyrecord ||
>>>>> locrecord || nxtrecord ||     naptrrecord || kxrecord || certrecord ||
>>>>> dnamerecord || dsrecord || sshfprecord || rrsigrecord || nsecrecord ||
>>>>> idnsname || idnszoneactive || idnssoamname || idnssoarname ||
>>>>> idnssoaserial || idnssoarefresh || idnssoaretry || idnssoaexpire ||
>>>>> idnssoaminimum || idnsupdatepolicy || idnsallowquery ||
>>>>> idnsallowtransfer || idnsallowsyncptr || idnsforwardpolicy ||
>>>>> idnsforwarders")
>>>>> (target = "ldap:///idnsname=*,cn=dns,$SUFFIX")(version 3.0;acl "Update
>>>>> DNS Entries";allow (write) userattr = "parent[0,1].managedby#GROUPDN";)
>>>>>
>>>>> I needed to add permission DN to the managedBy attribute so that I could
>>>>> create just one set of generic ACIs without having to create a set of
>>>>> ACIs for every new zone and thus let users with "Update DNS entries"
>>>>> permission have a write access to the "aci" attribute.
>>>>>
>>>>> Would this design be better than the previous one? Comments welcome.
>>>>
>>>> Removing Deny ACIs would be great.
>>>> But don't we need a second set of ACIs to allow uber admins to still
>>>> control all zones ? or is that part of current ACIs not going to
>>>> change ?
>>>>
>>>> Simo.
>>>>
>>>
>>> Thanks to the removal of the deny rule, this would be already allowed by
>>> this existing ACI:
>>>
>>> aci: (targetattr != "userPassword || krbPrincipalKey || sambaLMPassword
>>> || sambaNTPassword || passwordHistory || krbMKey || krbPrincipalName ||
>>> krbCanonicalName || krbUPEnabled || krbTicketPolicyReference ||
>>> krbPrincipalExpiration || krbPasswordExpiration || krbPwdPolicyReference
>>> || krbPrincipalType || krbPwdHistory || krbLastPwdChange ||
>>> krbPrincipalAliases || krbExtraData || krbLastSuccessfulAuth ||
>>> krbLastFailedAuth || krbLoginFailedCount || krbTicketFlags ||
>>> ipaUniqueId || memberOf || serverHostName || enrolledBy")(version 3.0;
>>> acl "Admin can manage any entry"; allow (all) groupdn =
>>> "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";)
>>
>> Oh right!
>> I like it even more then :-)
>>
>> Simo.
>>
> 
> Yes, this looks like it will work and eliminating a deny rule is a definite plus.
> 
> rob

I have finished a patch based on the second design. IMO it is indeed better -
no deny ACI for DNS and just a standard permission for per-zone access delegation.

There is just one difference from the proposed design draft: per-zone
permissions are not created automatically by Managed Entry plugin, but rather
manually and only for DNS zones where per-zone access is needed. There is a new
command for that - dnszone-add-permission.

This will leave permission tree cleaner + we won't have to deal with all
Managed Entry plugin machinery.

More details can be found in a commit message.

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-mkosek-277-2-per-domain-dns-record-permissions.patch
Type: text/x-patch
Size: 36430 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20120627/1296ff79/attachment.bin>