Projects/kadmin access interface

This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.

This project implements a pluggable interface to allow more flexible access control for kadmin operations.

Background

The kadmin facility allows administration of a Kerberos database in two ways. In the normal scenario, the kadmin client calls into libkadm5clnt, which authenticates to kadmind and transmits requests via an XDR-based protocol. kadmind executes the requests by calling into libkadm5srv, which in turns calls into libkdb5:

   kadmin --> libkadm5clnt ==> kadmind --> libkadm5srv --> libkdb5

Alternatively, an administrator can run kadmin.local on a KDC host (or with permissions to directly access the database, if LDAP or a similar KDB module is in use). kadmin.local can "authenticate" as any user, and directly calls into libkadm5srv to fulfill requests:

   kadmin.local --> libkadm5srv --> libkdb5

The current built-in access control mechanism is implemented at the kadmind layer, so it does not affect kadmin.local. It reads an ACL file which contains access rules, and checks the authenticated user and requested operation against the rules. The ACL file can also apply restrictions to add-principal and modify-principal operations, which may result in changes to the added or modified principal.

A pluggable interface for access control can solve two use cases:

1. Administrators can implement programmatic access control if the kadm5.acl format is not flexible enough. For instances, a module could allow users to create host principals for hosts in particular subdomains, which is currently not possible with kadm5.acl as we only allow wildcarding of whole principal components.
2. Projects which implement their own KDB module (particularly Samba and IPA) can use the database to control access.

Design

Architecture

One simple design option is to make kadmind tell the KDB module the authenticated client principal. The KDB module could then check access for subsequent operations such as put_principal and change_pwd. kadmin.local would not supply a client principal, so the KDB module would not check access control. This option does not satisfy the first use case and would require the administrator to install a permissive kadm5.acl file, but it would be easy to implement.

The design option most in keeping with our past designs is to create a pluggable interface for kadmin access control and convert the existing kadm5.acl code into a module for the interface. Multiple modules can be combined using the usual accumulator semantics for access control modules (a module can return yes, no, or pass; at least one module must say yes and zero modules must say no for an operation to succeed). If a shared object which implements a kadmin access control module also implements a KDB module, it can retrieve the KDB handle from the krb5_context operation to perform database operations.

Module interface

The existing kadm5.acl code has the following interface design:

• A set of operation types (ADD, DELETE, MODIFY, CHANGEPW, INQUIRE, EXTRACT, LIST, SETKEY, and IPROP)
• A check function which accepts a client principal, an operation type, and a target principal, and produces a success-or-failure status and an optional restriction object.
• An impose_restrictions function which accepts a kadm5_principal_ent_rec, mask, and restriction object, and applies the restrictions to the entry and mask.

Not all parameters of the check function apply to all operations. Restrictions are only applicable to the ADD and MODIFY operations when applied to principals, and the target principal is not applicable to the LIST operation, or to the ADD, DELETE, INQUIRE, and MODIFY operations when applied to policy objects.

Several options for the pluggable interface include:

1. A design similar to the above, with some possible variations:
   1. The restrictions object could be transparent, and applied by the krb5 code, so that the interface does not depend on a kadmin type.
   2. The restrictions object could be eliminated; instead, optional entry and mask parameters could be provided to the check function to be modified.
2. One method per operation, with parameters specific to the operation, and policy operations separated from principal operations.

Option 2 is elegant and easily extensible via the interface minor version, but would likely require a lot of repetitive accumulator code in the interface consumer.