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

Tue Aug 30 09:59:51 UTC 2016


On 30.08.2016 11:51, Standa Laznicka wrote:
> 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.
>

I agree, we should not mix this on old clients, I like the most the 
original proposal with switching objeclasses

Martin^2