[Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies

[Simo Sorce]

On Tue, 2016-08-30 at 08:47 +0200, Standa Laznicka wrote:
> On 08/26/2016 05:37 PM, Simo Sorce wrote:
> > On Fri, 2016-08-26 at 11:26 -0400, Simo Sorce wrote:
> >> On Fri, 2016-08-26 at 18:09 +0300, Alexander Bokovoy wrote:
> >>> On Fri, 26 Aug 2016, Simo Sorce wrote:
> >>>> On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote:
> >>>>>> I miss "why" part of "To be able to handle backward compatibility
> >>>>> with
> >>>>>> ease, a new object called ipaHBACRulev2 is introduced. " in the
> >>>>> design
> >>>>>> page. If the reason is the above - old client's should ignore time
> >>>>> rules
> >>>>>> then it has to be mentioned there. Otherwise I don't see a reason to
> >>>>>> introduce a new object type instead of extending the current.
> >>>>> How do you want to enforce HBAC rule that have set time from 10 to 14
> >>>>> everyday? With the same objectclass old clients will allow this HBAC
> >>>>> for
> >>>>> all day. Isn't this CVE?
> >>>> This is a discussion worth having.
> >>>>
> >>>> In general it is a CVE only if an authorization mechanism fails to work
> >>>> as advertised.
> >>>>
> >>>> If you make it clear that old clients *DO NOT* respect time rules then
> >>>> there is no CVE material, it is working as "described".
> >>>>
> >>>> The admins already have a way to not set those rules for older clients
> >>>> by simply grouping newer clients in a different host group and applying
> >>>> time rules only there.
> >>>>
> >>>> So the question really is: should we allow admins to apply an HBAC Rule
> >>>> potentially to older clients that do not understand it and will
> >>>> therefore allow access at any time of the day, or should we prevent it ?
> >>>>
> >>>> This is a hard question to answer and can go both ways.
> >>>>
> >>>> A time rule may be something that admins want to enforce at all cost or
> >>>> deny access. In this case a client that fails to handle it would be a
> >>>> problem.
> >>>>
> >>>> But it may be something that is just used for defense in depth and not a
> >>>> strictly hard requirement. In this case allowing older clients would
> >>>> make it an easy transition as you just set up the rule and the client
> >>>> will start enforcing the time when it is upgraded but work otherwise
> >>>> with the same rules.
> >>>>
> >>>> I am a bit conflicted on trying to decide what scenario we should
> >>>> target, but the second one appeals to me because host groups do already
> >>>> give admins a good way to apply rules to a specific set of hosts and
> >>>> exclude old clients w/o us making it a hard rule.
> >>>> OTOH if an admin does not understand this difference, they may be
> >>>> surprised to find out there are clients that do not honor it.
> >>>>
> >>>> Perhaps we could find a way to set a flag on the rule such that when set
> >>>> (and only when set) older clients get excluded by way of changing the
> >>>> objectlass or something else to similar effect.
> >>>>
> >>>> Open to discussion.
> >>> At this point using new object class becomes an attractive approach. We
> >>> don't have means to exclude HBAC rules other than applying them
> >>> per-host/hostgroup. We also have no deny rules.
> >>>
> >>> I have another idea: what about enforcing time rules always to apply
> >>> per-host or per-hostgroup by default? Add --force option to override the
> >>> behavior but default to not allow --hostcat=all. This would raise
> >>> awareness and make sure admins are actually applying these rules with
> >>> intention.
> >> This sounds like a good idea, but it is not a silver bullet I am afraid.
> >>
> >> Simo.
> > I was thinking that for future proofing we could add a version field,
> > then reasoned more and realized that changing the object class is
> > basically the same thing.
> >
> > There is only one big problem, ipaHBACRule is a STRUCTURAL objectclass.
> > (I know 389ds allows us to do an LDAPv3 illegal operation and change it,
> > but I do not like to depend on that behavoir).
> >
> > Now looking into this I had an idea to solve the problem of legacy
> > clients without having to swap classes.
> > We can redefine the accessRuleType attribute to be a "capability" type.
> >
> > Ie rules that have a timeAccess component will be of type
> > "allow_with_time" instead of just "allow".
> > Old clients are supposed to search with accessRuleType=allow (and I can
> > see that SSSD does that), so an older client will fail to get those
> > rules as they won't match.
> >
> > New clients instead can recognize both types.
> >
> > Also if we need a future extension we will simpy add a new access rule
> > type and we can have the same effect.
> > The nice thing is that accessRyleType is defined as multivalue (no
> > SINGLE in schema) so we may actually create compatible rules if we want
> > to.
> > Ie we could set both "allow" and "allow_with_time" on an object for
> > cases where the admin wants to enforce the time part only o newer client
> > but otherwise apply the rule to any client.
> >
> > This should give us the best of all options at once.
> >
> > Thoughts ?
> >
> > Simo.
> >
> Sorry to join the discussion so late, I was away yesterday.
> 
> I have to say I too like this idea much better than fiddling with the 
> objectClasses. Also, I believe that accessRuleType was originally 
> actually used to distinguish newer version of HBAC rules from the older 
> so we may just do this again and profit from its original purpose. To 
> top it off, this change should be really easy to implement to what I 
> currently have on SSSD side.
> 
> I was just wondering - would you propose for every newly created rule to 
> have the new accessRuleType set to "allow_with_time" or should the type 
> change with addition of time rules to the HBAC rule as it does 
> currently? Also, should the user be able to modify the type so that a 
> rule with the new type is also visible for older clients (=> he could 
> add "allow" to type anytime)?

Rules of type allow_with_time will not work on older clients, so we
should probably default to just the old "allow" schema.

I think in the first implementation the framework/cli/ui should not
emphasize this attribute but simply replace allow -> allow_with_time if
a time attribute is added.

In future we may give control of it and allow even to set multiple
values, after we discuss better if that should be done, and with ample
warnings to admins.

Also setting a time rule makes a rule incompatible with older clients so
we should spell it clearly in the CLI/UI with a warning message that
this rule will not apply at all to older clients.

> Thanks for your ideas, I am very happy with what you suggested here :)

Thank you.

Simo.

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