Projects/Extensible Policy
This project adds new extensions to policy records and makes them extensible in the future with less effort by adding a TL data extension.
Contents
Background
kadmin's policy records have been limited to expressing a small range of password quality policies. In 1.8 the failed authentication attempts lockout project added some extensions to the policy record.
We now need to add policy controls for what enctypes a principal is allowed to have keys for. While we are it we're adding fields to policy for all policy-ish things in principal records. And making policy finally extensible in the same way that principals are: via tag-length-value sets ("TL data").
Description and Architecture
We bump the KADM5 API version to 4 (KADM5_API_VERSION_4) and extend the policy structures (kadm5_policy_ent_rec and osa_policy_ent_rec) to add the following fields:
- attributes
- holds attributes of principals that are policy-like (not implemented at this time)
- max_life
- holds max ticket life (not implemented at this time)
- max_renewable_life
- holds max ticket renewable lifetime (not implemented at this time)
- allowed_keysalts
- key/salt type list that the principal is allowed to have keys of
- tl_data
- sequence of {type, length, octet string} values just as in principal records
User interface changes:
- The kadmin addpol and modpol commands get a new argument: -allowedkeysalts keysalt-list.
- The kdb5_util dump and load commansd get a new argument: -r18 (request 1.8 dump format).
API changes:
- New kadm5 version number
- Added fields to kadm5_policy_ent_
- Added KADM5_POLICY_{ATTRIBUTES, ...} flags for use in the 'mask' argument to various kadm5 functions
Note that, as with the change in 1.8, it will not be safe to downgrade a KDC from 1.11 to an earlier version without reloading the policy DB from a dump format that the older version understands. We hope this will be the last time that policies are extended in this manner; by using TL data for future extensions, we can obtain the same downgrade semantics as for the principal database.
Implementation
- Bump the KADM5 API version number everywhere that it should be, with fallback negotiation to versions 3 and 2
- Extend the relevant structures (see above)
- Refactor kadmin.c functions for adding and updating tl data (not needed now, but will be needed eventually)
- Add KADM5_POLICY_{ATTRIBUTES, ...} #defines for use in kadm5 masks
- Update XDR functions for encoding/decoding/freeing kadm5_policy_ent_rec and osa_policy_ent_rec structures
- Add and use check_and_set_ks_tuple_policy(), a utility function for validating and editing key/salt tuples in src/lib/kadm5/srv/svr_principal.c
A candidate implementation can be seen here:
Add "?w=1" to get the github equivalent of diff(1)'s -w flag.
We leave implementation of the 'attributes', 'max_life', and 'max_renewable_life' to future projects. Because these will provide defaults for corresponding fields of principals the impact on interfaces and implementation will be somewhat larger than that of the allowed_keysalts field.
Testing
One test is added: tests/t_allowed_keysalts.py. All tests pass.
NOTE: dump/load of policy TL data is not tested for lack of any policy elements that use TL data.
Documentation
The kadmin.M and kdb5_util.M manpages are updated.
Release notes
Besides the interface changes noted above, the most important release note pertains to the requirement for a policy DB reload when downgrading a KDC to a previous release. A policy DB reload is only needed on downgrade when new policies have been created, or existing policies modified, with the new kadmin program or kadm5 APIs.
