[Freeipa-devel] [PATCH] 277 Per-domain DNS record permissions

[Martin Kosek]

On Tue, 2012-06-19 at 15:16 +0200, Petr Viktorin wrote:
> On 06/19/2012 08:30 AM, Martin Kosek wrote:
> > On Mon, 2012-06-18 at 11:37 -0400, 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
> >>
> >
> > Ok, thank you both. I finished the patch, it should work fine for both
> > new installs and upgrades.
> >
> > After the upgrade, all you have to do to delegate read/write privileges
> > to the zone is this command:
> >
> > # ipa dnszone-add-managedby example.com --users=fbar
> >
> > fbar then will be able to actually see the zone with dnszone-show +
> > modify it. Delegated permissions have several limitations though:
> > 1) Delegated user cannot delete the zone
> > 2) Delegated user cannot add or remove another users to the managedBy
> > list
> >
> > Martin
> >
> 
> Would it be possible to delegate the rights to groups, not only to 
> individual users?
> 

It is possible, now we use this rule for the deny ACI:

(groupdn != "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX")
and (groupdn != "ldap:///cn=Read DNS Entries,cn=permissions,cn=pbac,$SUFFIX")
and not (userattr = "parent[0,1].managedby#USERDN")

We could add a group comparison this way:

(groupdn != "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX")
and (groupdn != "ldap:///cn=Read DNS Entries,cn=permissions,cn=pbac,$SUFFIX")
and (not ((userattr = "parent[0,1].managedby#USERDN")
          or (userattr = "parent[0,1].managedby#GROUPDN")))

+ add similar changes to add/delete/update ACIs.

There is just question if we want to add this capability. For example in
case of hosts, we also do not allow hostgroups in managedBy attribute.
Wouldn't this new parent[0,1].managedby#GROUPDN check increase the ACI
evaluation time? Simo, Rob?

Martin