[Freeipa-devel] [WIP] Add command to test HBAC rules

[Alexander Bokovoy]

On 22.07.2011 22:47, Rob Crittenden wrote:
> Alexander Bokovoy wrote:
>>
>> Now real patch: adds command, updates API.txt and VERSION files, along
>> with freeipa.spec.
>>
>>
>> On 22.07.2011 12:32, Alexander Bokovoy wrote:
>>> Hi,
>>>
>>> attached please find a first cut of an HBAC tester command to CLI,
>>> FreeIPA ticket https://fedorahosted.org/freeipa/ticket/386
>>>
>>> The idea behind this plugin is to re-use pyhbac module provided by SSSD
>>> project which is Python bindings for SSSD's libipa_hbac code used for
>>> actual HBAC rule execution. This requires libipa_hbac-python package.
>>>
>>> There are four modes implemented by the plugin given (user, source host,
>>> target host, service), attempt to login user coming from source host to
>>> target host's service:
>>>
>>> 1. Use all enabled HBAC rules in IPA database to simulate
>>> [root at host0 ~]# ipa  hbactest --user=a1a --srchost=foo --host=bar
>>> --service=ssh
>>> --------------------
>>> Access granted: True
>>> --------------------
>>>
>>> 2. Use all enabled HBAC rules in IPA database + explicitly specified
>>> (disabled) rules
>>> [root at host0 ~]# ipa  hbactest --user=a1a --srchost=foo --host=bar
>>> --service=ssh --rules=my-second-rule
>>> --------------------
>>> Access granted: True
>>> --------------------
>>>
>>> 3. Use only explicitly specified HBAC rules
>>> [root at host0 ~]# ipa  hbactest --user=a1a --srchost=foo --host=bar
>>> --service=ssh --rules=my-second-rule,new-rule --validate
>>> --------------------
>>> Access granted: True
>>> --------------------
>>>    Passed rules: new-rule
>>>    Denied rules: my-second-rule
>>>
>>> 4. Get detailed result of simulation for all enabled HBAC rules:
>>> [root at host0 ~]# ipa  hbactest --user=a1a --srchost=foo --host=bar
>>> --service=ssh  --validate
>>> --------------------
>>> Access granted: True
>>> --------------------
>>>    Passed rules: allow_all
>>>    Denied rules: my-second-rule, my-third-rule, myrule
>>>
>>> --validate option forces to run detailed simulation and report per-rule
>>> results. Results are: passed, denied, error. The latter one is for
>>> wrongly specified rules which should not be enabled.
>>>
>>> When --validate specified together with --rules, only HBAC rules
>>> specified on the command line are considered.
>>>
>>> I'm still not sure if running simulation against all disabled HBAC rules
>>> in databse is worth it.
> 
> For a first shot at writing a IPA plugin this is an excellent start, my
> comments are mostly corner cases.
Thanks!

> I wanted to see what would happen with an incomplete rule:
> 
> $ ipa hbacrule-show test2
>   Rule name: test2
>   Enabled: TRUE
> 
> $ ipa hbactest --rules=test2
> User name: admin
> Source host: panther.example.com
> Target host: puma.example.com
> Service: login
> --------------------
> Access granted: True
> --------------------
> 
> I believe this should have failed.
No, it shouldn't -- you are testing all enabled rules + one explicit
(which would be tested anyway as it is enabled) -- this is mode (2) of
my write up above. And most likely you have allow_all rule that gives
you login.

if you would run
$ ipa hbactest --validate

you would see it.

> If I pass in --validate with the same input I get:
> 
> ---------------------
> Access granted: False
> ---------------------
>   Denied rules: test2
> 
> So this is a little confusing. I thought --rules limited the rules that
> were considered. Maybe I'm misunderstanding it.
--validate + --rules gives limitation, --rules alone adds more rules to
the existing test set which is all enabled rules in IPA.

> It would also be nice to have a way to validate a rule without having to
> supply all the options, sort of a "is this rule even legal?". When first
> working with hbac rules it is hard to remember that all parts (users,
> services, hosts and sourcehosts) all need to be defined or the rule is
> invalid.
libipa_hbac evaluates rule against (user, source host, target host,
service) tuple so you need to have certain values in order to test the
rule...

> You don't need to explicitly include required=True in your Parameters,
> it is the default.
Ok.

> In output you can define them as Str instead of List. List is more for
> input, it automatically parses comma-separated data.
Will change that.

> The text in the examples wraps a fair bit on an 80-character screen.
Yep. I'm interested also in seeing whether parameters as they are make
sense. If they do, I'll rework examples. Particulary, this distinction
between existing rules and --rules= needs clarification in order to
avoid confusion for admins.

> If you pass in an non-existing rule to --rules it is ignored, at least
> with --validate.
Should it cause an error? I do not check right now whether all rules
from --rules= are found and added.

> I assume that unit tests are coming since this is still a WIP. Writing
> one at this point might help with the corner cases.
yes.

-- 
/ Alexander Bokovoy