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

Dmitri Pal dpal at redhat.com
Mon Jul 25 13:46:41 UTC 2011


On 07/25/2011 07:59 AM, Alexander Bokovoy wrote:
> On 22.07.2011 23:10, Alexander Bokovoy wrote:
>>> 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.
> I reworked a bit command line interface to avoid confusion like that.
>
> # ipa hbactest --help
> Usage: ipa [global-options] hbactest [options]
>
> Options:
>   -h, --help     show this help message and exit
>   --user=STR     User name
>   --srchost=STR  Source host
>   --host=STR     Target host
>   --service=STR  Service
>   --rules=LIST   Rules to test. If not specified, all enabled rules are
> tested
>   --detail       Detail rule execution
>   --all          Include all enabled IPA rules into test
>
> Now if you specify --rules, hbactest will only try to simulate login
> using these rules. You would need to add --all to force considering all
> IPA enabled rules.

I like the functionality but --all does not sound right, may be it
should be --enabled or something else.

> When no --rules are specified, simulation is run against all enabled IPA
> rules.
>
> --validate got replaced by --detail which simply tries to run simulation
> one by one and report results for each rule. You can apply it for any
> run, with or without --rules and --all.

May me --detail should something like --each or --checkeach or
--iterate. The expectation about the term "detail" is a bit different.
The functionality seems OK though.

> If --rules contains a name of non-existent rule, it is simply ignored.
> So if I asked to verify against --rule=foobar where there is no such
> rule, Should there be error message for such cases? Right now you'll get
> False (access is not granted) and --detail will not show any rules.

It should be an error IMO. The reason is that you might have miss-typed
something and think you checked the rule that you miss-typed but it
would turn out that you did not.

> Now, the only mode left out is batch verification of all disabled rules
> for purpose of checking their correctness.

The more I think about it the more I lean towards just having --disabled
to include all disabled rules instead of listing them explicitly in
--rules. It is more a convenience aggregation than any different in
behavior.

>  Suppose we have a switch
> --show-invalid that takes all IPA rules and runs a simulation request
> against them, reporting the ones that are invalid only. 

Invalid in what way? I am not sure we can detect validity of the rules.
The whole point of the tool was to detect whether a real or test user
will be denied or allowed and whether it is expected or not.

> Such a request
> could be done without any specific (user, source host, target host,
> service) tuple because we are only interested in HBAC_EVAL_ERROR return

I am not sure I understand. What kind of condition would return such an
error?

> code which is independent of input parameters. Unfortunately all we can
> tell in this case is that rule is incorrect, without much details.
> Probably some improvement for libipa_hbac is needed, like converting
> request result into a bit field and returning detailed cause of error
> per tuple element.
>
>
> Current version is attached. It still lacks unit tests.
>
>
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20110725/b8519fc4/attachment.htm>


More information about the Freeipa-devel mailing list