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

[Standa Laznicka]

On 08/30/2016 09:34 AM, Standa Laznicka wrote:
On 08/30/2016 09:23 AM, Alexander Bokovoy wrote:
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.
I do realize that (even though I touched this in my first question) 
but this solution seems a bit cleaner to me.

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.

+1, why not to use it if there's no other use for it anyway.

Actually, I gave it a further thought - the problem with using 
accessRuleType for this purpose would be that even the new rules that 
older clients can't evaluate correctly would be displayed/listed in 
WebUI/hbacrule-find results. I do not think this should happen, it is 
confusing.

I should also say explicitly that I do NOT think that if a time rule is 
set for an HBAC rule this HBAC rule should still be taken into account 
during evaluation on an old client. To base the decision whether to 
allow/not-allow access purely on a client version is just wrong.

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code