[Freeipa-devel] Notes and questions for fine-grained read permissions
Petr Viktorin
pviktori at redhat.com
Thu Sep 5 17:07:41 UTC 2013
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.
# 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).
# 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"
# Compat tree
Do we want to reuse the read privileges for the compat tree, or create
extra ones?
# 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?
# 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.
--
Petr³
More information about the Freeipa-devel
mailing list