[Freeipa-devel] More types of replica in FreeIPA

[Simo Sorce]

On Thu, 2012-04-19 at 17:26 +0200, Ondrej Hamada wrote:
> >>> Sorry, I wrote it unclear. I meant that the credentials, we store on
> >>> Consumer should be there available only for a specified period of time.
> >> Why ?
> >>
> >>> After that time they should be flushed away (means they are still valid,
> >>> just not stored on the Consumer), no matter what is their expiration
> >>> time.
> >> I do not see what's the point. If we are replicating the keys to a
> >> consumer why would it try to delete them after a while ?
> Security? My original idea was, that if consumer gets corrupted, there 
> should be stored as less credentials as possible. This behaviour should 
> mainly flush credentials of users, who don't auth against the consumer 
> regularly. All the paragraphs about flushing credentials below were 
> inspired by this idea.

Ah but you may be worsening security if you do that, because now you
need to add a pull mechanism where you allow consumer to read keys off
of a master. A better way would be to gather statistics and have
available reports admins can check to trim consumer membership lists
(these lists determine what users should have their credentials
replicated to the consumer).

> >> Either the user is marked as part of the location server by this
> >> consumer, and therefore we replicate keys or we do not. We cannot delete
> >> keys, as nothing would replicate them back to us until a password change
> >> occurs. Also, you have no way to tell the master what it should
> >> replicate, dynamically.
> >> I would remove this point, it is not something we need or want, I think.
> The point was that not only the credentials will be removed, but also 
> the user will be unmarked.

Which means the consumer need to be able to change group memberships on
the master, which means it will probably also be able to add them, so in
the end we open up a venue for an attacker to play with these lists and
potentially force a master to send us all keys.
Sounds brittle to me.

> >> For account lockouts we will need to do an explicit write to a master.
> >> (probably yet another plugin or an option to the password plugin). We
> >> cannot use replication to forward this information, as consumers do not
> >> have a replication agreement that go from consumer to master.
> If the consumers and hubs were masters in fact, it would be possible to 
> replicate it. But if we can manage it via plugin and thus keep then 
> consumers/hubs to be really read-only, then it's definitely a better 
> solution.

If the consumers were masters and they could replicate we'd had no
security, as they would be able to change all the rules that block
replication back easily enough. Or at the very least poison the data in
the masters.
I think rule 0 here is that consumers do not write to masters, ever, and
when they have to for some reason (like locking accounts) they should go
through a very strict and limited extended operation that does the
operation on their behalf.

Simo.

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