[Freeipa-devel] per-group password policy proposal

[Simo Sorce]

On Thu, 2009-06-11 at 18:30 -0400, Dmitri Pal wrote:
> Simo Sorce wrote:
> > On Thu, 2009-06-11 at 17:34 -0400, Dmitri Pal wrote:
> >   
> >> Sorry Simo I disagree. I think it is too complex, hard to mange and
> >> not deterministic enough.
> >>     
> >
> > Can you explain where you see a problem, it seem pretty simple to me.
> >   
> I see a problem in determining what policy was used when something 
> happened in the past.

Well unless you plan to keep track of all changes in DS you would have
the same problem with either mechanism, so I would rule this
consideration out as a decisive factor.

> Also the CoS is a complex notion and would be hard for admins to 
> understand how to manage.

Yes, but nobody is proposing that admins create the CoS objects by hand,
just like we don't make them create taskgroups/rolegroups and delegation
rules by hand.
I assume Rob has a CLI/UI interface in mind where all you do is:
1. Create new password policy 
2. Associate password policy to a group

This looks quite simple to me :)

> What is simple to you does not mean simple  for others. And you even 
> acknowledged the complexity yourself.

Yep the details of CoS can be complex, but we I do not think we plan to
require admins to manually set up CoS.

> > You need to be able to be able to write to groups to change users
> > memberships, so I don't see where there is an access control problem.
> >   
> You might have a right to create and nest groups and you will mess your 
> environment by not understanding the impact.

If you do not understand how to mange groups you should not manage
groups. However the worst that can happen with nesting is that some user
get a stronger policy. So this is not a "security" problem.

> With update case you can only ever affect users that you can access and 
> you can't do the operation inadvertently.

This is true for anything handled through groups, HBAC for example.
People that are given authority over managing groups must be trained
people, and have enough "clearance" anyway.
Remember that group memberships may also control access to files on disk
on the ipa clients.
If we want to allow junior admins to manage groups then we need to find
a way to have some access control wrt what they can add to the 'member'
attribute.

> You have to actually go and apply the policy. With groups approach you 
> can create a new nesting and not realize that it affected password 
> policies in the way you did not expected or wanted.

If you use password policy specific groups this is unlikely. If you nest
password policy specific groups inadvertently then something is wrong in
your training or in the security policies of your company.

> Finally to check what policy is active for the user you just quesry the 
> user and see that if he has policy attributes this is the policy that 
> applies, if he does not than the default one is used.
> Very simple, logical and easy to work with.

This is the same with CoS. With a single query you know what policy
applies to the user. No difference here.

> >> So admin has to have the rights to do so. He will be able to only
> >> modify policies for the users that he can access.
> >>     
> >
> > I think that password policies should be managed primarily through
> > groups that are used only to convey password policies. These groups
> > should be manageable only by admins that have enough privileges to
> > change password policies. I don't see an access control problem here.
> >   
> I agree with the statement. But difference is that the groups will be 
> used to define the set of users to which the policies should apply.

Yes, this is what we are proposing, not sure if you are objecting to
something here ?

> >> With Rob's proposal one can mess with the group nesting and not
> >> realize that he weakened the policies for the highly sensitive
> >> accounts.
> >>     
> >
> > You can't weaken policies, because weaker policies have a lower Cos
> > Priority, so they will never "win" when multiple policies are available
> > for the same user. Always the highest (== most restrictive wins).
> >
> >   
> Poor auditor...

I really don't understand. You can see, with a single query, what is the
policy applied to a specific user. Why should the auditor have any
problem ??

> >> I think we can add this kind of functionality later on top of the
> >> direct updates if the users complain.
> >>     
> >
> > Direct updates are cumbersome prone to fail and cause a lot of
> > unnecessary traffic (therefore also slow). I really don't see any
> > advantage.
> >   
> If it is done the plugin it is not remote.

More code to build, when we already have a working infrastructure we
just need to use.

> It is not a frequent operation so performance issues are not that important.

ok

> It is a major security thing - it does not happen every day.

Yes, in both cases.

> It should not be dynamic as you propose and the price is even better to 
> discourage admin to flip-flop and take this seriously.

I don't agree on this, managing password policies should be a privileged
operation anyway, and any privileged operation should be taken
seriously. If you don't making it more difficult will not make people
take it more seriously, rather it will discourage people from using
better policies and will encourage then to keep using default or even
lax policies for everybody by changing only the default password policy.

> If the update failed the CLI or UI should just report it back letting 
> admin to take a corrective action.

You don't want to deal with failures on security features, this is one
of the reasons I prefer CoS to bulk changes.

> >> I doubt they will. Keep in mind that the PRD item was written having 
> >> bulk update in mind.
> >>     
> >
> > Yes, but I see no risk here.
> > If you mess up managing groups or determining password policies or their
> > priorities you can also mess up bulk updates.
> >   
> I suggest we ask the freeipa-users about these two alternatives and see 
> what the community will say.
> May be I am wrong but I have seen problems with the flexible group 
> approach in the past so I do not like it.

Well, people interested in technical details should probably be
subscribed to this list :-)
But we can probably invite people on freeipa-users to look at this
thread (point to the archives) and ask them to comment on this list if
they have any strong opinions.

Simo.

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