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

[Petr Vobornik]

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

My point is that the design is missing the explanation.

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


-- 
Petr Vobornik