logo_kerberos.gif

Difference between revisions of "Projects/kadmin access interface"

From K5Wiki
Jump to: navigation, search
(Architecture)
(Module interface)
Line 46: Line 46:
 
# A design similar to the above, with some possible variations:
 
# A design similar to the above, with some possible variations:
 
## The restrictions object could be transparent, and applied by the krb5 code, so that the interface does not depend on a kadmin type.
 
## The restrictions object could be transparent, and applied by the krb5 code, so that the interface does not depend on a kadmin type.
## The restrictions object could be eliminated; instead, optional entry and mask parameters could be provided to the check function to be modified.
+
## The restrictions object could be eliminated; instead, optional entry and mask parameters could be provided to the check function to be modified. (However, note that renames are denied if the ACL entry for the client principal imposes any restrictions on the modify operation, which might be harder to detect with this design.)
 
# One method per operation, with parameters specific to the operation, and policy operations separated from principal operations.
 
# One method per operation, with parameters specific to the operation, and policy operations separated from principal operations.
 
# A few methods grouped by operation class, such as "principal operation", "policy operation", and "general operation".
 
# A few methods grouped by operation class, such as "principal operation", "policy operation", and "general operation".

Revision as of 15:46, 11 June 2017

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 high-level 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 (or would perhaps only supply one if specifically requested), 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.

Another option, similar to the above, is to amend the kadm5_hook pluggable interface to receive the client principal, either by revising the five existing methods (chpass, create, modify, remove, rename) or by adding a new method to specify the client principal for subsequent operations. This option is not a great fit for the first use case because the kadm5_hook interface only addresses the subset of kadm5_operations which alter principal entries, not those which affect policy objects or those which only request data. It might be helpful, if not completely sufficient, for the second use case insofar as it allows control of set-password operations. As with the first option, this option would require the administrator to install a permissive kadm5.acl file, as kadm5_hook operates at a lower layer than kadm5.acl.

The 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.

The remainder of this page will assume the third option.

Module interface

The existing kadm5.acl code resides in libkadm5srv, but is only used by kadmind and could be moved there. It 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. (However, note that renames are denied if the ACL entry for the client principal imposes any restrictions on the modify operation, which might be harder to detect with this design.)
  2. One method per operation, with parameters specific to the operation, and policy operations separated from principal operations.
  3. A few methods grouped by operation class, such as "principal operation", "policy operation", and "general operation".

The consumer interface in kadmind need not precisely reflect the module interface. For example, if the module interface uses option 2, it would be possible to reduce the amount of redundant accumulator code by making the consumer interface look more like option 1 or 3.