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

[Jan Cholasta]

On 18.5.2016 13:00, Petr Spacek wrote:
> On 18.5.2016 12:52, Jan Cholasta wrote:
>> On 18.5.2016 12:43, Stanislav Laznicka wrote:
>>> On 05/18/2016 12:38 PM, Jan Cholasta wrote:
>>>> On 18.5.2016 12:23, Petr Spacek wrote:
>>>>> On 18.5.2016 08:25, Stanislav Laznicka wrote:
>>>>>> On 05/17/2016 12:40 PM, Petr Spacek wrote:
>>>>>>> On 13.5.2016 13:50, Stanislav Laznicka wrote:
>>>>>>>> Hello list,
>>>>>>>>
>>>>>>>> We had a discussion today over integrating the Time Rules into the
>>>>>>>> CLI and
>>>>>>>> WebUI and a problem came up with with the current solution. It
>>>>>>>> seems that
>>>>>>>> while having templating handled by CoSTemplates might be nice in
>>>>>>>> terms of easy
>>>>>>>> dereferencing on SSSD side (it's handled by the DS itself), it's
>>>>>>>> not really
>>>>>>>> much possible to pick one string from the multi-valued accesstime
>>>>>>>> attribute of
>>>>>>>> HBAC Rule object and modify it.
>>>>>>> Could you be more specific?
>>>>>>>
>>>>>>> AFAIK LDAP protocol allows this. Where is the problem?
>>>>>>>
>>>>>>> Petr^2 Spacek
>>>>>> I should have added we're talking CLI and WebUI here.
>>>>>>
>>>>>> Imagine you have 5 values of the accesstime attribute, each one is
>>>>>> about 10
>>>>>> lines of iCal string, and want to change one:
>>>>>>
>>>>>> ipa hbacrule-mod-accesstime rule_name --time=???
>>>>>
>>>>> I see. In DNS plugin we do it this way:
>>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-master-dns-zones.html#examples-add-modify-record-cli
>>>>>
>>>>>
>>>>>
>>>>> $ ipa dnsrecord-mod example.com www --a-rec 192.0.2.123
>>>>> --a-ip-address 192.0.2.1
>>>>>
>>>>> I would argue that naming of the options is weird so something easier to
>>>>> understand could be made. E.g.
>>>>> $ ipa hbacrule-mod-accesstime rule_name --orig-time=??? --time=???
>>>>
>>>> NACK, the dns plugin should not be used as an example for anything, as
>>>> it breaks almost every convention in the framework.
>
> Good point :-)
>
>>> Also, typical iCalendar string is not much suitable for this approach
>>> (see http://tools.ietf.org/html/rfc5545#section-4 for examples). Your
>>> proposal is a way, of course, but not much user-friendly here.
>>>>
>>>> Removing and adding of particular accesstime values should be done by
>>>> a pair of commands, "hbacrule-add-accesstime rule_name accesstime" and
>>>> "hbacrule-remove-accesstime rule_name accesstime".
>>>>
>>> What about modifications, thought? If not for CLI, you will still need a
>>> way to modify a more complex time rule in the WebUI (you do not want to
>>> remove a complex rule just to click through its creation all again for a
>>> minor change).
>>
>> Modification of an attribute value is exactly that - the old value gets
>> removed and the new value gets added. How it will look like in the web UI is a
>> completely different thing.
>
> The question here is if the intermediate state without defined time (remember,
> no transactions!) is acceptable or not.
>
> Does it mean that the time restriction will removed OR that access will be
> always denied because the rule is incomplete?

I certainly hope that this will be implemented in such a way that it's 
the latter :-)

>
> Petr^2 Spacek
>
>>
>>>>>
>>>>>>>> We were thinking of a solution discussed way earlier - having our
>>>>>>>> own time
>>>>>>>> rule objects that could be referenced from each HBAC rule. That
>>>>>>>> way, any time
>>>>>>>> rule could be modified easily. As the HBAC rules are cached on the
>>>>>>>> SSSD side
>>>>>>>> periodically using the deref plugin, there should be no problem of
>>>>>>>> inconsistency with the server database.
>>>>>>>>
>>>>>>>> The original reasoning pro and against the proposed solution could
>>>>>>>> be found on
>>>>>>>> the pad
>>>>>>>> http://pad.engineering.redhat.com/ipa-time-based-HBAC-design. It
>>>>>>>> would
>>>>>>>> be really nice to hear your opinions and ideas that could help us
>>>>>>>> overcome
>>>>>>>> this problem.
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> Standa


-- 
Jan Cholasta