Extensible kadm5 policies

[Simo Sorce]

On Sun, 2011-10-30 at 17:06 -0500, Nico Williams wrote:
> 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".

Ok, it doesn't necessarily mean it is a good design you want to 'port'
to other implementations.

> As for ugliness, yes, it's ugly, but the current policy DB mess is far
> uglier,

Doesn't justify adding more ugliness IMO.

> and for the following reasons:
> 
>  - The protocol and API treat policies as non-extensible.

This may or may not be a problem. But I wouldn't mind the ability to add
plugins.

> This can always be fixed by adding new RPCs and new APIs.

Let's do that if feasible.

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

Why would you treat principals and policies as sub-classes of the same
type ? This really escapes me.

>  - The protocol and API allow for just one policy per-principal.

This is because there is no grouping mechanism within the KDC.
I guess this is because 'groups' are considered already to be part of
the 'authorization' realm.
Adding groups w/o breaking implementations that worked around this issue
by implementing groups and policies in their own DAL is necessary and
needs to be done carefully.

> This is OK when we're talking about trivial password quality policies,

To be honest, no it is not ok and that's why in IPA we implemented
password policies that apply to multiple principals at the same time.
We took the route of doing this in our own modules instead of pushing
stuff in the KDC. May not be the best way and I have no objection on
making this kind of functionality available in the KDC itself, as long
as this doesn't make the KDC less flexible than it is today.

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

Yeah, not sure if you looked into how group policies (let's for a moment
put aside that 'Group policies' is a overloaded name, where policies is
mostly configuration as well as security policies) work, but it is quite
a mess there too.
I agree it makes it a powerful tool in the right hands, but I am not
sure I would necessarily look at that as a 'good' example for how to
handle policies .

> This too can be fixed by adding new things to the protocol and API, of course.

As long as that is perceived as a problem that needs to be solved within
the KDC (as opposed to a plugin for example) then yes.

>  - 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 guess there might be, I would rather put all this in a few neat
plugins, and make it possible to store custom data in the KDC.
Having opaque objects in the DB would make it also possible to store
this stuff in the main DB and suitable modifications of the propagation
protocol might then make it possible to push stuff around.

But to be honest I wonder why going all that trouble when most of the
features you want are much easier to implement by using a more
sophisticated database backend like LDAP, which is much more flexible
and would be able to support the changes you need much more easily, and
replication as well as multi-master support often comes for free too ...

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

Is this per principal ? To override the supported enctypes ?
What's the use case ? Why the default support enctypes list is not ok ?

> One alternative design would be to add new types of policies.
> Hopefully just one more type, this one being extensible.

How do you handle 'extensible' policy types ? Just shove opaque blobs
into 'generic' containers and then rely on plugins to 'parse' and
understand these blobs ?
Why can't you use TL_DATA (with the new stuff to store arbitrary
string/value pairs) ?
If this is because you need to have policies for groups of principals,
how do you plan to handle relations between policies and principals ?
Custom grouping mechanisms for each opaque 'extension' ?
Or are you going to propose a design for how to group principals so that
multiple extensions can use the same groups ?

>   Such a
> design would -presumably- add new APIs and RPCs and DBs or DB entry
> formats and possibly key naming.

Yup, seem like what needs to be done if you really think this is
material for the reference implementation.

> My design does not avoid new APIs; it only avoids new RPCs, though the
> protocol does get changed in terms of semantics.

If you have to change semantics then you can change RPCs as well, it is
semantically the same thing, only you make it clear to everyone, and not
hidden.

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

I wouldn't call it just an implementation detail, and the reason to do
it seem not very strong. What is preventing you from proposing a design
without these hacks ?

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

For consumers, yes. For the core, and long term maintainability, no.

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

If you need new concept I think you need more code, and new interfaces,
I do not see what you gain by bloating existing interfaces adding new
meanings instead of building proper interfaces.

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

Reuse of generic code is generally a good idea. Refactoring of code to
have more generic interfaces for similar problems also is generally a
good idea.
"Reuse" by changing semantics is generally a terrible idea, leads to
unexpected consequences and breaks contracts for existing users.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York