[Freeipa-devel] [Update]Time-Based Account Policies

[Martin Basti]

On 13.11.2015 16:40, Simo Sorce wrote:
> On 13/11/15 10:17, Martin Basti wrote:
>>
>>
>> On 13.11.2015 14:41, Simo Sorce wrote:
>>> On 11/11/15 09:30, Martin Basti wrote:
>>>>
>>>>
>>>> On 11.11.2015 14:52, Martin Basti wrote:
>>>>> Comments inline
>>>>> Martin^2
>>>>>
>>>>> On 11.11.2015 09:24, Stanislav Laznicka wrote:
>>>>>> On 11/05/2015 06:17 PM, Petr Spacek wrote:
>>>>>>> On 4.11.2015 15:20, Martin Basti wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> we (Standa and I) had offline discussion and I proposed following
>>>>>>>> idea:
>>>>>>>>
>>>>>>>> 1) create new entry in LDAP for "time rule" instead of adding the
>>>>>>>> time rule
>>>>>>>> string directly into HBACRule.
>>>>>>>> This will allow to reuse time rules among various HBAC Rules (and
>>>>>>>> maybe in
>>>>>>>> future with sudo rules, etc.)
>>>>>>>> HBACrule gets only reference to time rule entry stored in LDAP db.
>>>>>>> Good idea! I can see time rule entry 'working hours in Brno
>>>>>>> office' which is
>>>>>>> linked to relevant HBAC rules.
>>>>>> This seems like a good idea. However, it might be a bit messy to 
>>>>>> have
>>>>>> even the least significant rules stored in separate objects. But I
>>>>>> agree. It brings some questions, though.
>>>>> Imo to have separate entry for time rule is cleaner than add it
>>>>> directly to HBAC rule.
>>>
>>> I really disagree, see below.
>>>
>>>>>> Where would be a good spot to store these time rules?
>>>>> As I originally thought that we can share time rules between HBAC,
>>>>> SUDO and everything else, I couldn't be wrong more.
>>>>>
>>>>> Example: HBAC admin have permission to edit HBAC rule, but doesn't
>>>>> have permission to edit SUDO rule. The HBAC admin should be able to
>>>>> edit time rules for HBAC rules, and cannot be able to edit time rules
>>>>> of SUDO rules. Thus time rules must be separated between HBAC, SUDO
>>>>> and others, and privilege that give the permission to modify HBAC
>>>>> rule, must give permission to modify only HBAC time rules.
>>>>>
>>>>> I suggest to add HBAC time rules to HBAC container.
>>>> After IRC discussion with pspacek and jcholast:
>>>>
>>>> We should just create separated privileges to time rules and allow 
>>>> them
>>>> to be shared.
>>>> So they should be stored in new container in LDAP
>>>
>>> I do not understand what this means.
>>>
>>> And in general I am opposed to have a separate object on performance
>>> grounds (for clients) and also on the fact that is becomes tricky to
>>> keep objects in sync.
>> What exactly is the performance issue there? To download extra entry
>> from LDAP?
>
> Yes because now you have to download rules, parse them, find out what 
> needs tro be downloaded and pull it, or wore just download all time rules
>
>> The SSSD do the same sync with users and groups, doesn't it?
>
> No, by default we do not enumerate users and groups, and for HBAC 
> rules we download only those that apply to the machine.
>
> All this exactly to reduce the amount of time taken, and load on the 
> server.
>
>>>
>>> We then have to deal with cases where you delete a time object but an
>>> HBAC still references it and also assuring you have permissions to
>>> fully change an HBAC rule, you may end up in situations where you can
>>> change the HBAC rule for everything but the times (or vice versa).
>> IMO this should solve referint plugin if the time policy is removed,
>> then it will be removed from HBAC rules as well.
>
> This is *not* ok though, you do not want an HBAC rule that limits 
> users to a specific time to suddenly become "any time" because someone 
> removed a time rule and didn't know it was referenced by multiple rules.
> These are exactly the type of issues you end up having when you split 
> the rule in multiple objects.
>
>>>
>>> So please, explain carefully what would require a separate time object.
>>>
>>> On privileges alone I see no value in a separate privilege for time
>>> than for the HBAC object it applies to (preference for using the same
>>> object). I also see no technical reason to store the time rules for
>>> completely different stuff in the same tree.
>>> Yes, there may be the odd case in which you want to have the same time
>>> rule for a sudo rule and an HBAC rule, we can make that easy in the
>>> interface by providing a "copy time rules from X" kind of interface.
>> My original suggestion was to have it separated, HBAC time policy under
>> HBAC container and sudo time policy under sudo container. So HBAC admin
>> will have access to the same subtree and the one can modify time policy
>> for HBAC. However pspacek and jcholast disagree I will let them to
>> explain the reasons.
>
> Seriopusly, the HBAC time policy should be (on the HBAC rule object) 
> and I mean it as an additional object class with the policy embedded 
> in the specific HBAC rule. This is more efficient and avoid issues 
> like the one above.
>
> Can you explain *why* you propose to have separate objects ? What's 
> the rationale ? What are the failure modes ?
>
The main purpose is to have time policies like "Work hours in Brno", 
"Work hours in Brisbane" ... which can be associated with many HBAC 
rules, instead of adding a separate time policy for each HBAC rule.

Martin
> Simo.
>