Extensible kadm5 policies

[Nico Williams]

On Sun, Oct 30, 2011 at 4:43 PM, Simo Sorce <simo at redhat.com> wrote:
> On Fri, 2011-10-28 at 11:54 -0500, Nico Williams wrote:
>> 1) Treat policies as principals named with a well-known naming
>> convention to avoid collisions;
>
> I don't g4et this, but it sounds ugly and something I wouldn't like to
> see.

Aside from whether it's ugly, Heimdal already does it, though for just
one policy, the one named "default".

As for ugliness, yes, it's ugly, but the current policy DB mess is far
uglier, and for the following reasons:

 - The protocol and API treat policies as non-extensible.  This can
always be fixed by adding new RPCs and new APIs.  But if the elements
of policies can all be elements of principals, then this feels like a
crappy design too -- in an OO design we might sub-class principals and
policies from a common base class.

 - The protocol and API allow for just one policy per-principal.  This
is OK when we're talking about trivial password quality policies, but
not OK in a world of more complex policies.  Windows allows multiple
GPOs to apply to a user (or a host) for a reason.  This too can be
fixed by adding new things to the protocol and API, of course.

 - Implementation issues...  Such as (in MIT krb5):

    - Separate DB for policies, with separate locks, and attendant
bugs (e.g., incorrect policy reference count upkeep, though there the
obvious solution is to stop reference counting policies!).

    - Propagation issues.

There's probably more I'm not thinking of.

I'm open to different designs, as long as we end up with extensible
policies.  At the very least I need a way to express one additional
policy: enctypes allowed for long-term keys at key/password change
time.

One alternative design would be to add new types of policies.
Hopefully just one more type, this one being extensible.  Such a
design would -presumably- add new APIs and RPCs and DBs or DB entry
formats and possibly key naming.

My design does not avoid new APIs; it only avoids new RPCs, though the
protocol does get changed in terms of semantics.  My design does get
rid of the additional DB and various issues, but not entirely free of
hackiness (namely: that policies represented as principals would have
to have some elements that make no sense for policies as a result of
DB entry format and/or representation on the wire, but this would be
an implementation detail).  Indeed, whatever we do with the protocol,
as long as we add new APIs the choice of representation of policies
really would be an implementation detail.

It'd be fair to argue that being willing to add new APIs should imply
willingness to add new RPCs.  New RPCs would add more code that would
not have to be added the other way. but hey, it's just bloat :) but
it'd hardly be the end of the world (and either way we'd end up with
more types for the TL_DATA typed-hole or whatever policy
representations end up using).

I'll admit that my design is tempting in large part due to ease
coding, since it re-uses existing building blocks.  Most of the time
we think of re-use as a very good thing, but I'll grant that it
needn't always be so, and that this might be one case where it isn't.

Nico
--