Managed_Read_permissions

Managed_Read_permissions#

Overview#

The IPA framework will handle default permissions more robustly with respect to IPA updates and user-made changes.

In the future, this allow us to create a system of fine-grained, user-controllable permissions with good defaults and predictable behavior over upgrades.

Use Cases#

Modifications to permissions that come with FreeIPA by default will be restricted to changing the attribute lists and bind types.

For example, attempting to change a default “Modify Users” permission to apply to Groups will fail:

$ ipa permission-mod 'System: Modify Users' --type=group
ipa: ERROR: invalid 'ipapermlocation': not modifiable on managed permissions

So will attempting to make it apply to Read operations:

$ ipa permission-mod 'System: Modify Users' --right=read,
ipa: ERROR: invalid 'ipapermright': not modifiable on managed permissions

On the other hand, making the permission not apply to the “gecos” attribute is possible:

$ ipa permission-mod 'System: Modify Users' --excludedattrs=gecos
------------------------------------------
Modified permission "System: Modify Users"
------------------------------------------
  Permission name: System: Modify Users
  Granted rights: write
  Effective attributes: businesscategory, carlicense, cn, description, displayname, employeetype, facsimiletelephonenumber, givenname, homephone, inetuserhttpurl, initials, l, labeleduri, loginshell, manager, mepmanagedentry, mobile, objectclass, ou, pager, postalcode,
                        preferredlanguage, roomnumber, secretary, seealso, sn, st, street, telephonenumber, title, userclass
  Excluded attributes: gecos
  Default attributes: telephonenumber, cn, labeleduri, manager, street, displayname, homephone, title, facsimiletelephonenumber, loginshell, employeetype, description, businesscategory, preferredlanguage, roomnumber, mepmanagedentry, carlicense, postalcode, givenname,
                      pager, seealso, objectclass, inetuserhttpurl, l, st, mobile, gecos, sn, ou, secretary, userclass, initials
  Bind rule type: permission
  Subtree: cn=users,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com
  Type: user
  Granted to Privilege: Modify Users and Reset passwords, User Administrators
  Indirect Member of roles: helpdesk, User Administrator

So is changing the bind rule type, i.e. making a permission apply to all authenticated users, anyone including anonymous users, or specific users selected by privileges:

$ ipa permission-mod 'System: Read User Membership' --bindtype=anonymous
--------------------------------------------------
Modified permission "System: Read User Membership"
--------------------------------------------------
  Permission name: System: Read User Membership
  Granted rights: read, compare, search
  Effective attributes: memberof
  Default attributes: memberof
  Bind rule type: anonymous
  Subtree: cn=users,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com
  Type: user

Documentation draft#

This section explains the behavior from the user’s point of view:

“Managed” permissions are those permissions that come pre-installed with IPA, and are updated in new releases to cover new functionality. They behave like regular, user-created permissions, with these differences:

  • Their name, location and target can not be modified

  • They cannot be deleted (but note that setting default bindtype and removing from all privileges will effectively disable a permission)

  • They have three sets of attributes:

    • default attributes, managed by IPA, cannot be changed by the user

    • included attributes (–includedattrs in the CLI) are extra attrs that the user has added

    • excluded attributes (–excludedattrs in the CLI) are those that the user has removed

The permission applies to all attributes that appear in either its default or included sets, but not in its excluded set.

It is possible to control the effective attributes using permission-mod’s –attrs option, as with other permissions. The modifies the included and excluded lists so that the effective list matches the request.

(Note that attributes of user-created permissions work the same way, but since the default and excluded sets are empty, only the included set determines the effective attributes.)

Newer versions of IPA may add additional attributes to the default set. Attributes added this way should be listed in the corresponding Release Notes. If some of the new attributes are undesirable, add them to the corresponding excluded list before the upgrade.

All managed permissions currently have the “System:” prefix in their name, to prevent naming clashes between user-created permissions and future IPA defaults.

In FreeIPA 4.0, most default permissions have been turned into Managed ones. Some permissions still use the old “SYSTEM” scheme (i.e. they are not modifiable, but may be only assigned to privileges). A list of these permissions follows:

  • Add Automember Rebuild Membership Task

  • Add Replication Agreements

  • Certificate Remove Hold

  • Get Certificates status from the CA

  • Modify DNA Range

  • Modify Replication Agreements

  • Remove Replication Agreements

  • Request Certificate

  • Request Certificates from a different host

  • Retrieve Certificates from the CA

  • Revoke Certificate

  • Write IPA Configuration

Upgrade considerations#

When upgrading to IPA 4.0, the process will convert old default permissions, such as.

ipa-3-3$ ipa permission-find 'Modify Groups'
--------------------
1 permission matched
--------------------
  Permission name: Modify Groups
  Permissions: write
  Attributes: cn, description, gidnumber, objectclass, mepmanagedby, ipauniqueid
  Type: group
  Granted to Privilege: Group Administrators
  Indirect Member of roles: User Administrator
----------------------------
Number of entries returned 1
----------------------------

to managed ones, e.g.

$ ipa permission-find 'System: Modify Groups'
--------------------
1 permission matched
--------------------
  Permission name: System: Modify Groups
  Granted rights: write
  Effective attributes: cn, description, gidnumber, ipauniqueid, mepmanagedby, objectclass
  Default attributes: cn, objectclass, mepmanagedby, gidnumber, ipauniqueid, description
  Bind rule type: permission
  Subtree: cn=groups,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com
  Type: group
  Granted to Privilege: Group Administrators
  Indirect Member of roles: User Administrator
----------------------------
Number of entries returned 1
----------------------------

If the default permissions that come with IPA have been modified, special care should be taken when upgrading.

Removed default permissions#

If a default permission was removed, the upgrade process will simply create a new default permission. This is consistent with to how all IPA upgrades work.

Changed attribute lists#

If only the attribute list differs from a past default, the permission updater will set the included/excluded lists of the new default permission to match the modifications.

Note that the updater considers default values from all past IPA versions. Be sure to check the result after updating.

Other ACI changes#

If any other changes were made to a default permission, the updater emits a warning and does not create the new permission. In this case, there are two options:

1) Delete the old permission (e.g. ipa permission-del 'Modify Groups'), then run ipa-ldap-updater -p. This will create the new default permission.

2) Change the old permission to a new-style (V2) permission by issuing e.g. ipa permission-mod 'Modify Groups' on a server with IPA 4.0+, then run ipa-ldap-updater -p. This will also create the new default permission, but the old one will be preserved as a user-created permission.

The problem#

Currently, updates to permissions that come with IPA are specified in .update files.

This approach has the disadvantage that if the user modifies the permission, the updater will not recognize it, so it will end up not being updated. This may result in reduced functionality (if needed attributes are not added), or security issues (if attributes are not deleted).

Design#

Managed Permissions#

V2 permissions with the MANAGED flag set are called Managed permissions.

These permissions grant access to a set of attributes defined by IPA and kept up-to-date on upgrades, while allowing users to add or remove specific attributes from the default list.

The user can also manage the bind rule and privilege membership of Managed permissions.

The other aspects of Managed permissions (name, location, target) are not modifiable by the user. The user cannot manually add new Managed permissions, or delete existing ones (unless –force is applied; but later we may restrict this via ACIs).

To ensure that installing low-version replicas or disabling plugins does not revoke access to existing data, the default list of attributes will be kept in LDAP as ipaPermDefaultAttr. Users can not modify this list via the framework. On updates, new attributes will only be added to this list. (To remove attributes, we would need to write a separate update plugin.)

There will be two attribute types for holding attributes the admin added and removed: ipaPermIncludedAttr and ipaPermExcludedAttr respectively. (In user-created permissions, ipaPermIncludedAttr is used for the same purpose as here, and excluded & default are empty.) See V3/Permissions V2 for the schema definition.

When generating the ACI, the resulting attribute list will be computed by taking the ipaPermDefaultAttr set, adding any ipaPermIncludedAttrs, and then removing any ipaPermExcludedAttrs.

For example, this permission:

dn: cn=Read Users,cn=permissions,cn=pbac,$SUFFIX
cn: Read Users
ipaPermDefaultAttr: cn
ipaPermDefaultAttr: sn
ipaPermDefaultAttr: givenName
ipaPermDefaultAttr: l
...
ipaPermIncludedAttr: favoriteColor
ipaPermExcludedAttr: givenName
objectClass: top
objectClass: groupOfNames
objectclass: ipaPermission
objectclass: ipaManagedPermission
ipaPermType: SYSTEM
ipaPermType: V2
ipaPermType: MANAGED
ipaPermLocation: cn=users,cn=accounts,$SUFFIX
ipaPermRight: read
ipaPermTarget: uid=*,cn=users,cn=accounts,$SUFFIX
ipaPermBindRuleType: permission

would allow users to read all default user attributes except givenName, plus additionally favoriteColor.

CLI & API#

The permission-{mod,find} commands will gain two new options, --includedattrs (API: ipapermincludedattr) and --excludedattrs (API: ipapermexcludedattr). For permission-mod it is an error to use --excludedattrs with non-managed permissions.

For a managed permission, the permission-{mod,find,show} commands will output all three lists (ipapermdefaultattr, ipapermallowedattr, ipapermexcludedattr), as well as the computed list of effective attributes.

For a non-managed permission, permission-{mod,find,show} will only output the effective attributes (attrs). With --all, the included attributes will also be included. As any missing attribute course excluded and default will not be output. With --raw, only ipaPermIncludedAttr, and not attrs, wil be output.

It is an error to set the ipapermlocation, ipapermtargetfilter, or ipapermtarget of a managed permission. (This means that it’s an error to ise the API options subtree, extratargetfilter, target, memberof, targetgroup, or type with a managed permission.)

Default Permission Updater#

A server post-update plugin will walk through ipalib Object plugins and create/update managed permissions pertaining to them.

Names of such default permissions are required to start with “System: “, so that default permissions added in future IPA releases do not conflict with user-created permissions. The “:” character will not be usable in permission-add. (It will be usable in permission-mod and permission-del, where managed permissions are subject to the limitations stated above.)

The IPA Object plugins will gain a new Python attribute, managed_permissions, which will hold a template for the permissions that are to be added by default to manage that object.

This will allow plugins to be more self-contained; it will no longer be necessary to modify IPA’s update files to add the common cases of plugin-specific permissions.

The format of the managed_permissions templates will be documented in the update_managed_permissions server plugin (link).

Replacing legacy default permissions#

Another entry in the managed_permissionstemplate, replaces, will be used for replacing legacy permissions with new managed ones. Example:

managed_permissions = {
    'ipa:Modify SUDO Rule': {
        'ipapermbindruletype': 'permission',
        'ipapermright': {'write'},
        'ipapermdefaultattr': {
            'description', 'ipaenabledflag', 'usercategory',
            'hostcategory', 'cmdcategory', 'ipasudorunasusercategory',
            'ipasudorunasgroupcategory', 'externaluser',
            'ipasudorunasextuser', 'ipasudorunasextgroup', 'memberdenycmd',
            'memberallowcmd', 'memberuser'
        },
        'replaces': [
            '(targetattr = "description || ipaenabledflag || usercategory || hostcategory || cmdcategory || ipasudorunasusercategory || ipasudorunasgroupcategory || externaluser || ipasudorunasextuser || ipasudorunasextgroup || memberdenycmd || memberallowcmd || memberuser")(target = "``\ ```ldap:///ipauniqueid=`` <ldap:///ipauniqueid=>`__\ ``*,cn=sudorules,cn=sudo,$SUFFIX")(version 3.0;acl "permission:Modify Sudo rule";allow (write) groupdn = "``\ ```ldap:///cn=Modify`` <ldap:///cn=Modify>`__\ `` Sudo rule,cn=permissions,cn=pbac,$SUFFIX";)',
        }
    },
    ...

If the an existing legacy (i.e. non-v2) permission exists either without an associated ACI or with an ACI that exactly matches the information specified in the replaces list, the old permission is removed after the new one is added.

This ensures that

  • the old permission is retained if the user has changed it

  • at no time are the ACIs revoked (briefly, there are two ACIs granting the same access).

If an existing legacy permission does match cn but not some other attributes in the replaces dict, a warning is logged, the new permission is added, and the old one is left in place.

The exception are attributes. If the ACI only differs in the list of attributes, the permission is upgraded as notmal but with ipapermincludedattr and ipapermexcludedattr set to reflect the difference between the old default and the pre-existing permission.

Removing the global anonymous read ACI#

After the permission updater successfully runs, it will look for an ACI named “Enable Anonymous access” in $SUFFIX, and remove it.

The update_anonymous_aci server update plugin will be removed.

ACI.txt#

To ensure that permission changes are properly reviewed, a summary file similar to API.txt will be generated, and it will be checked on each build.

It will contain a summary of the default managed permissions.

A makeaci script similar to makeapi will be provided and called to check the file on each build.

Implementation#

No additional requirements or changes discovered during the implementation phase.

Feature Managment#

UI

The immutable aspects of Managed permissions are grayed out in the Web UI.

CLI

See the CLI & API section in Design.

Major configuration options and enablement#

Access control is configured via the existing RBAC system.

Replication#

N/A, ACIs and permissions are replicated.

Updates and Upgrades#

Old servers will not be able to modify Managed permissions, except adding/removing them to/from prigileges. Details are in Permissions V2, which will be implemented in the same release. Managed permissions use the MANAGED flag.

Installations with customized ACIs will need some extra care when upgrading, as detailed in Upgrade considerations above. (But note that IPA’s upgrade behavior wrt modified default permissions has always been underspecified and likely surprising.)

Dependencies#

No new package and library dependencies.

External Impact#

Tests and documentation need to be written.

Backup and Restore#

ACIs, permissions, privileges and roles are already included in backup & restore.

Test Plan#

RFE Author#

Petr Viktorin

Category:FreeIPA V4 Test Plan Category:FreeIPA Test Plan

Contents