2012/5/4 Kohei KaiGai <kaigai@xxxxxxxxxxxx>:
> 2012/5/4 Stephen Smalley <sds@xxxxxxxxxxxxxx>:
>> On Fri, 2012-05-04 at 15:48 +0200, Kohei KaiGai wrote:
>>> Does anyone have a tool to run regression test when we construct a patch?
>>> (Or, is it available to construct using existing tools?)
>>>
>>> Right now, I have to replace a working policy by the modified one whenever
>>> I prepare to submit a patch towards reference policy. However, the default
>>> security policy of Fedora is optimized to Fedora environment, thus, it often
>>> mismatch with the latest upstream policy.
>>> For example, "allow_execmem" is not defined at Fedora, so, I could not
>>> load the staff.pp being constructed based on the upstream policy
>>>
>>> So, the solution I'm looking for is a tool that loads a monolithic policy and
>>> checks its access control decision towards a certain pair of subject context
>>> and target context according to catalog files, then it prints the result of
>>> diff commands between the computed one and expected one.
>>
>> Possibly you could derive such a tool from checkpolicy -d, switching
>> from a menu-driven interface to a scriptable one.
>>
>> checkpolicy -Mdb /etc/selinux/targeted/policy/policy.24
>>
>> setools would be the other option, but sesearch only deals with TE
>> rules.
>>
> Thanks for your suggestion. I totally agree with the idea to expand
> checkpolicy to accept a script that describes a set of patterns to be
> checked. I'll try to investigate it in this weekend.
>
I tried to implement an infrastructure of regression test to cover
wider test cases, without replacement of existing environment.
It consists of two portions. The first one is a new script support at
checkpolicy command. It allows to give a script to check access
control decision of the loaded policy, and print out its results
towards a pair of security contexts.
The other one is a test case in reference policy. It should contain
a set of test cases described as a script of checkpolicy and expected
result for each policy types (standard, mcs and mls). If and when
someone applied a patch to the reference policy, he can confirm
how it works or unexpected side-effect as differences from the
expected results.
The current revision towards checkpolicy supports the following
commands.
* access <scontext> <tcontext> <tclass>
It prints all the allowed permissions for a pair of contexts.
* create <scontext> <tcontext> <tclass> [<objname>]
It prints a security context to be assigned on a new object
if and when <scontext> creates a new one under the <tcontext>.
The <objname> is optional, but not supported yet, because
libsepol does not support to query named type transition.
* boolean <bool name> [<new value>]
It shows or turns on/off a particular boolean. It should be used
to confirm permissions being allowed conditionally.
At the reference policy side, I create "regtest" directory to store
test cases and expected results. I works towards only monolithic
policy, so you can try the regression test as follows.
[kaigai@iwashi refpolicy]$ make MONOLITHIC=y TYPE=mcs regtest
:
/usr/bin/checkpolicy: policy configuration loaded
/usr/bin/checkpolicy: writing binary representation (version 27) to policy.27
Regression Test for postgresql ... ok
Regression Tess Pass
This make target runs the test cases (*.test) stored in the "regress"
directory to the checkpolicy, then it compares its output with
expected results (*.expected).
If regtest-$(TYPE).diff is not empty, it means diff command generate
something different from expected results.
I'd like to have such kind of test in the reference policy, to cover
wider range test cases at security policy side.
It helps to improve the quality and to reduce the burden for testing.
(In fact, I found a few bugs in mcs/mls rules during this development...)
Thanks,
--
KaiGai Kohei <kaigai@xxxxxxxxxxxx>
Attachment:
selinux-refpolicy-regtest.20120506.patch.gz
Description: GNU Zip compressed data
Attachment:
selinux-checkpolicy-regtest.20120506.patch
Description: Binary data
