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

[Standa Laznicka]

On 08/30/2016 09:34 AM, Standa Laznicka wrote:
> On 08/30/2016 09:23 AM, Alexander Bokovoy wrote:
>> On Tue, 30 Aug 2016, Jan Cholasta wrote:
>>> On 30.8.2016 08:47, 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.
>>>
>>> Note that the resulting code will be exactly the same except for the 
>>> attribute name - you won't be fiddling with objectClass but with 
>>> attributeRuleType.
> I do realize that (even though I touched this in my first question) 
> but this solution seems a bit cleaner to me.
>>>
>>>> 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.
>>>
>>> The original purpose was to support deny rules, but they were 
>>> deprecated.
>>>
>>>> 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)?
>>>>
>>>> Thanks for your ideas, I am very happy with what you suggested here :)
>>>
>>> TBH I'm not - I don't find adding hacks on top of obsolete 
>>> deprecated stuff to be a particularly appealing solution to anything.
>> It is just an attribute. Reusing an attribute that is not used anymore
>> for anything else is not a bad thing. The original solution may be
>> deprecated but the schema is in place and will be almost forever, so
>> using otherwise unused but present schema is just fine.
>>
> +1, why not to use it if there's no other use for it anyway.
>
Actually, I gave it a further thought - the problem with using 
accessRuleType for this purpose would be that even the new rules that 
older clients can't evaluate correctly would be displayed/listed in 
WebUI/hbacrule-find results. I do not think this should happen, it is 
confusing.

I should also say explicitly that I do NOT think that if a time rule is 
set for an HBAC rule this HBAC rule should still be taken into account 
during evaluation on an old client. To base the decision whether to 
allow/not-allow access purely on a client version is just wrong.