[Freeipa-devel] Notes and questions for fine-grained read permissions

[Rob Crittenden]

Petr Viktorin wrote:
> Hello,
> I have some notes and questions on
> https://fedorahosted.org/freeipa/ticket/3566 (Control access of user
> roles to server functions).
>
>
> An IPA terminology refresher for reference:
> - ACI: The DS-level permission.
> - Permission: IPA object that encapsulates one ACI. Example: "add user".
> Permissions aren't as flexible as raw ACIs.
> - Privilege: IPA object that groups several permissions, e.g. with a
> "manage users" privilege you can "add user", "modify user", ...
> - Role: IPA object that groups privileges, e.g. an "User Administrator"
> can manage users and groups. Roles are assigned to users/groups/hosts.
>
>
> # Permission structure
>
> I think it would be best to have two permissions for each object, one
> for the entries and one for the container. This keeps the ACIs
> manageable with existing permission API:
>
> aci: (target = "ldap:///cn=*,cn=groups,cn=accounts,$SUFFIX")(version
> 3.0;acl "permission:Read Groups";allow (read,search,compare) groupdn =
> "ldap:///cn=Read Groups,cn=permissions,cn=pbac,$SUFFIX";)
>
> aci: (target = "ldap:///cn=groups,cn=accounts,$SUFFIX")(version 3.0;acl
> "permission:Read Group Container";allow (read,search,compare) groupdn =
> "ldap:///cn=Read Group Container,cn=permissions,cn=pbac,$SUFFIX";)
>
> These would be combined in a "Group Readers" privilege.
>
> All the privileges would be granted to a role called "Users", which
> would contain ipausers and admins.

I'm not sure I follow, what are you trying to achieve here? The more 
ACIs the slower the processing.

> # External users & system accounts
>
> I'm not sure how to handle external users here, since they're not added
> to any group. Either we'll need a special ACI for them, or somehow make
> it possible to add non-group sets of users to Roles.
>
> The same goes for system accounts, except those aren't even implemented
> in IPA yet (https://fedorahosted.org/freeipa/ticket/2801).

I think they would have to be part of a group. Otherwise 389-ds has 
nothing to evaluate against (and even with groups I'm not 100% sure 
it'll work).

>
> # Protected attributes
>
> How to handle passwords and other non-public attributes? I'm thinking
> about keeping a global list of such attributes, and applying it to each
> read permission ACI on normal operations and upgrades; either generating
> a (targetfilter != ...) clause or filtering the (targetfilter = ...) one.
> Possibly that list would be configurable and stored in LDAP.
>
> For reference, we currently exclude these in the anonymous read rule:
> "userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword
> || passwordHistory || krbMKey || userPKCS12 || ipaNTHash ||
> ipaNTTrustAuthOutgoing || ipaNTTrustAuthIncoming"

It could get ugly real fast, and potentially cause a lot of extra 
processing. I think the object(s) for each attribute should be 
considered so these wouldn't have to be applied to every ACI but only 
those that are affected. We don't need to worry about userPassword in 
groups, for example.

>
> # Compat tree
>
> Do we want to reuse the read privileges for the compat tree, or create
> extra ones?

I don't think so.

>
>
> # Combining read rights
>
> I think (read, search, compare) should be exposed in permission objects
> as a single right. Or is there a reason to keep it split?

Yes, they are separate for a reason. Using only search and compare isn't 
common, but it isn't unheard of either. For example, to be able to 
detect the presence of an attribute you can provide just the search 
permission.

>
> # P.S.
>
> I believe that we should strive to put our info about default
> permissions, containers, settings, and the schema for each plugin in the
> actual plugin module, rather than it all being split across several
> ldif/update files. This would make this data more manageable,
> introspectable and consistent, expose dependencies between plugins, and
> make it possible to actually write self-contained plugins.
> This should be done when the time comes for a new version of the
> ldap-updater.

I don't think we really have any problems having a more or less 
monolithic set up now. I think this would just add complexity.

rob