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

[Alexander Bokovoy]

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.
>
>>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.

-- 
/ Alexander Bokovoy