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

[Martin Kosek]

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";)

Martin