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

Thu Sep 1 12:14:16 UTC 2016

On 1.9.2016 14:09, Standa Laznicka wrote:
> On 09/01/2016 01:26 PM, Standa Laznicka wrote:
>> On 08/31/2016 12:57 PM, Petr Spacek wrote:
>>> On 31.8.2016 12:42, Standa Laznicka wrote:
>>>> On 08/30/2016 03:34 PM, Simo Sorce wrote:
>>>>> 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.
>>>>>
>>>> So - can we all agree on a solution?
>>>>
>>>> I took an extra half an hour and created the accessRuleType solution on
>>>> top of
>>>> what I currently have, see patches attached to get the picture what the
>>>> change
>>>> would mean for what I currently have in
>>>> https://github.com/stlaz/freeipa/tree/timerules_2 and
>>>> https://github.com/stlaz/sssd/tree/freeipa-trac-547_2. Note that the sssd
>>>> patch is really just to get a picture, it currently causes sssd_be to core
>>>> dump, not sure why and don't want to waste time debugging it right now.
>>>>
>>>> I myself would in the end rather go for objectClasses implementation as new
>>>> rules are not shown to old clients which seems correct as there's no
>>>> confusion
>>>> for admins who might scratch their heads at old clients with no idea why
>>>> their
>>>> HBAC rules don't apply otherwise.
>>> +1, I agree with Standa and Martin Basti. Let me repeat myself:
>>>
>>> I like the idea of "capabilities" in general but it needs proper design and
>>> detailed specification first.
>>>
>>> Given that we have to modify SSSD anyway, I would go for ipaHBACRulev2 object
>>> class with clear definition of "capabilities" (without any obsolete cruft).
>>>
>>> That should be future proof and without any negative/unforeseen impact to
>>> existing clients + it matches what Jan Pazdziora plans to do for HBAC+URI.
>>>
>> As there were no further objections, the latest changes with the objectclass
>> implementation that were made according to Honza's suggestions were pushed
>> to appear in the pull request https://github.com/freeipa/freeipa/pull/23.
>>
> To be explicit: Currently, I go with the new objectClass ipaHBACRuleV2 which
> differs from ipaHBACRule in removal of obsolete attributes, namely
> accessRuleType, sourceHost, sourceHostCategory and accessTime. This new
> objectClass makes the rules of the newer type invisible to the older clients
> on both FreeIPA and SSSD sides.
> 
> The class ipaHBACRuleV2 is dynamically switched to from ipaHBACRule upon
> addition of a time rule to a certain HBAC rule. The process is reversed when
> there're no time rules left in that exact HBAC rule. Therefore rules that may
> still apply on older clients are visible there, while the new rules that would
> not apply are not.

To make sure we thought about this:
What is your vision about interaction with future HBAC+URI (potentially also
HBAC+URI+time)?

-- 
Petr^2 Spacek