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

[Simo Sorce]

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.

-- 
Simo Sorce * Red Hat, Inc * New York