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

[Dmitri Pal]

On 07/25/2011 09:46 AM, Dmitri Pal wrote:
> 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.

Catching up with the thread I see that there is a discussion about the
invalid rules i.e. incomplete rules. I thought that it is nearly
impossible to create an "invalid" rule this way as the omitted parts
have the default interpretation if the value is missing. Those should be
clearly documented BTW. But I remember that the original designs touched
on this subject.
I looked here: http://www.freeipa.org/page/DS_Design_Summary#HBAC_object
It is somewhat defined somewhat not. Let us clear what is the meaning
of  empty users attribute. Is it "any" possible user, "rule is ignored"
or error. IMO it is any possible user. Same with host or service. But I
am open for argument.

>
>> 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/
>
>
>
> _______________________________________________
> 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/e45e21de/attachment.htm>