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

[Petr Vobornik]

On 08/26/2016 12:47 PM, Standa Laznicka wrote:
> On 08/26/2016 12:39 PM, Martin Basti wrote:
>>
>>
>> On 26.08.2016 12:37, Petr Vobornik wrote:
>>> On 08/26/2016 12:23 PM, Martin Basti wrote:
>>>>
>>>> On 26.08.2016 12:20, Alexander Bokovoy wrote:
>>>>> On Fri, 26 Aug 2016, Jan Cholasta wrote:
>>>>>> On 26.8.2016 11:55, Martin Basti wrote:
>>>>>>>
>>>>>>> On 26.08.2016 11:43, Jan Cholasta wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 11.8.2016 12:34, Stanislav Laznicka wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> I updated the design of the Time-Based HBAC Policies according
>>>>>>>>> to the
>>>>>>>>> discussion we led here earlier. Please check the design page
>>>>>>>>> http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The
>>>>>>>>> biggest
>>>>>>>>> changes are in the Implementation and Feature Management
>>>>>>>>> sections. I
>>>>>>>>> also added a short How to Use section.
>>>>>>>> 1) Please use the 'ipa' prefix for new attributes:
>>>>>>>> memberTimeRule ->
>>>>>>>> ipaMemberTimeRule
>>>>>>>>
>>>>>>>>
>>>>>>>> 2) Source hosts are deprecated and thus should be removed from
>>>>>>>> ipaHBACRuleV2.
>>>>>>>>
>>>>>>>>
>>>>>>>> 3) Since time rules are defined by memberTimeRule, accessTime
>>>>>>>> should
>>>>>>>> be removed from ipaHBACRuleV2.
>>>>>>> ad 2) 3)
>>>>>>>
>>>>>>> Because backward compatibility, ipaHBACRuleV2 must contain all
>>>>>>> attributes from ipaHBACRule as MAY
>>>>>> Not true.
>>>>>>
>>>>>>> With current approach, when timerule is added to HBAC, we just
>>>>>>> change
>>>>>>> objectclass from 'ipahbacrule' to 'ipahbacrulev2' so we keep all
>>>>>>> attributes that was defined in older HBAC. Removing any attrs from
>>>>>>> ipaHBACRuleV2 can cause schema violation.
>>>>>> Which is perfectly fine.
>>>>>>
>>>>>>>
>>>>>>> I'm not sure if want to handle this in code (removing deprecated
>>>>>>> attributes from HBAC entry when timerule is added)
>>>>>> We don't have to do anything. If any of the deprecated attributes are
>>>>>> present when you change the object class (which they shouldn't
>>>>>> anyway), you'll get schema violation, otherwise it will work just
>>>>>> fine.
>>>>>>
>>>>>>> I realized that AccessTime is MUST for 'ipahbacrule', so when
>>>>>>> timerule
>>>>>>> ('ipahbacrulev2') is removed and somebody deleted accesstime we
>>>>>>> have to
>>>>>>> add it back.
>>>>>> It is MAY. The only MUST attribute is accessRuleType, but that is
>>>>>> deprecated as well and should be removed from ipaHBACRuleV2. We only
>>>>>> support allow rules, so when timerule is removed, that's the value
>>>>>> you set accessRuleType to.
>>>>> SSSD does search for HBAC rules by '(objectclass=ipaHBACRule)' filter.
>>>>> Changing to ipaHBACRuleV2 means these rules will not be found by older
>>>>> SSSD versions and therefore people will experience problems with older
>>>>> clients not being able to use new rules even if they would lack time
>>>>> component.
>>>>>
>>>> Older client do not support timerules, so they should not search for
>>>> them. HBAC without timerules will be still have 'ipaHBACRule'
>>>> objectclass and will work with old clients. Only HBAC with timerules
>>>> will have assigned 'ipaHBACRuleV2'
>>>>
>>>> Martin^2
>>> 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.
>>
> It's exactly that - I will mention it there, then.

Thanks

>> 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?
>>
> Word.
>>>
>>>
>>> 2. About API and CLI: wasn't there an idea to hide/not provide
>>> --icalfile=file.ics and --time=escaped_icalstring  options in the first
>>> implementation. So that we can limit the support scope to only a subset
>>> of option(the  OPTS part). If arbitrary ical is allowed since the
>>> beginning then we are asking for a lot of bugs filed.
>>>
>>
> Why hide it if there's no real problem with it? The string/content only
> has to be cut down to the restrictions of one event per VCALENDAR but I
> do not see the problem there.
> 

OK then.
-- 
Petr Vobornik