Extensible kadm5 policies

[Nico Williams]

On Sun, Oct 30, 2011 at 10:59 PM, Simo Sorce <simo at redhat.com> wrote:
> On Sun, 2011-10-30 at 17:06 -0500, Nico Williams wrote:
>>  - 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.

The problem with plugins is that we'd not get away from having local
code that should really be upstream.  If MIT adds plugins instead of
new policy elements, well, that's just punting expression, storage,
retrieval, and evaluation of extended policy to the users.

On the plus side, more plugins would be better than nothing.  In a
pinch it'll do.

>> This can always be fixed by adding new RPCs and new APIs.
>
> Let's do that if feasible.

Greg proposes adding a new kadm5 version, if I understood correctly.
I'd rather do that, even though the idea that the types of the kadm5
functions' arguments depend on the version of the API requested by the
app... makes me nauseous :/

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

Because I can't think of any fields in a policy that couldn't also
legitimately be fields of a principal (except for the policy's name).
If we had any high variance policy-like fields, then those ought to be
fields of principals; on the flip side, low variance policy fields
should not be fields of a principal.  But we can't really be 100%
certain as to what policy fields could legitimately vary widely from
principal to principal at some site or another.

>>  - The protocol and API allow for just one policy per-principal.
>
> This is because there is no grouping mechanism within the KDC.

Policies sure are a sort of grouping facility, very similar to AD
GPOs, although much, much more primitive.

> I guess this is because 'groups' are considered already to be part of
> the 'authorization' realm.

Mailing lists are groups too.  Some types of groups are useful for
authorization, some aren't.

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

The antecedent of "this" in the quoted text was "The protocol and API
allow for just one policy per-principal."  I don't understand the
response in that context.

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

I would.  I would love to hear your thoughts as to why GPOs (let's
call them that, since that's what MSFT calls them) are a mess.

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

That's just punting to the customer.  Makes me sad.

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

Not always.  And I don't have the luxury of using LDAP at this time anyways.

Also, Heimdal's kadmin(1) command's sub-commands can work with the
local DB, but also with AD, LDAP, and remote Heimdal kadmin servers.
This happens at the kadm5 layer.  It's very, very convenient: one
command works with all backends (with some limitations, of course).

The kadm5 API is not all that terrible.  The TL DATA stuff is a bit of
a mess, but can be abstracted somewhat.

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

Doesn't have to be; we want it per-policy.  Yes.

> What's the use case ? Why the default support enctypes list is not ok ?

Migration to strong enctypes.

We have principals that we need to mark as "strong", that are never
allowed to get 1DES keys again once they have been marked as strong.
And we have principals that, for whatever legacy code issues, are
still stuck using 1DES, so we mark them as "weak".  We overload policy
_names_ to glean which enctype policy applies to a given principal.

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

Yes,

> Why can't you use TL_DATA (with the new stuff to store arbitrary
> string/value pairs) ?

Because policies today don't have that (they aren't principals! :)

> If this is because you need to have policies for groups of principals,

Policies are groups, effectively.

> how do you plan to handle relations between policies and principals ?

I was hoping same as today: via a policy field in the principal that
names the applicable policy.

> Custom grouping mechanisms for each opaque 'extension' ?

No.

> Or are you going to propose a design for how to group principals so that
> multiple extensions can use the same groups ?

I don't follow.

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

The semantic change is backward-compatible.

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

Unless the question of whether policy elements should also be elements
of principals is answered with a "yes", then the concept of applying a
modicum of OOP here helps reuse code / reduce new code.

I think that's the really interesting question here.

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

*Can* be.  Can we find some such unexpected consequences here?
Specifically, what would break?  (I think nothing would break, but I'm
not sure as to unexpected consequences.)

Nico
--