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

[Standa Laznicka]

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.