Thread: sepgsql: label regression test failed

Could you show me semodule -l on your environment?
I believe security policy has not been changed between F19 and F20...

Thanks,

2013/12/18 Sergey Muraviov <sergey.k.muraviov@gmail.com>:
> Hi
>
> I've tried to test postgres 9.3.2 and 9.4devel with selinux on Fedora 20 and
> met with a label regression test failure.
>
> PS
> I've got some warning during build process.
>
> --
> Best regards,
> Sergey Muraviov
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>



-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

Hello,

It seems to me changes in the base security policy on Fedora affected to
the regression test. Our test cases for sepgsql_setcon() utilizes the MCS
rules, that prevents domain transition from narrow categories to wider ones,
to control the success cases and failure cases.

However, its coverage was changed. It was applied all the domains in the
system, thus "unconfined_t" domain had been enforced by MCS rules.
But now, it shall be applied only domains with "mcs_constrained_type"
attribute.

[kaigai@vmlinux tmp]$ diff -up old/policy/mcs new/policy/mcs     :<snip>     :mlsconstrain process { transition
dyntransition}
 
-       (( h1 dom h2 ) or ( t1 == mcssetcats ));
+       (( h1 dom h2 ) or ( t1 != mcs_constrained_type ));

Probably, we need to define a domain by ourselves for regression test to ensure
the test stability, not using the system "unconfined" domain that has different
meaning by release.

I'll make a patch. Please wait for a while.

Thanks for your test & reports.

2013/12/18 Sergey Muraviov <sergey.k.muraviov@gmail.com>:
> # semodule -l | grep sepgslq
> sepgsql-regtest 1.07
>
> Full list of modules is in attachment.
>
>
> 2013/12/18 Kohei KaiGai <kaigai@kaigai.gr.jp>
>>
>> Could you show me semodule -l on your environment?
>> I believe security policy has not been changed between F19 and F20...
>>
>> Thanks,
>>
>> 2013/12/18 Sergey Muraviov <sergey.k.muraviov@gmail.com>:
>> > Hi
>> >
>> > I've tried to test postgres 9.3.2 and 9.4devel with selinux on Fedora 20
>> > and
>> > met with a label regression test failure.
>> >
>> > PS
>> > I've got some warning during build process.
>> >
>> > --
>> > Best regards,
>> > Sergey Muraviov
>> >
>> >
>> > --
>> > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
>> > To make changes to your subscription:
>> > http://www.postgresql.org/mailpref/pgsql-hackers
>> >
>>
>>
>>
>> --
>> KaiGai Kohei <kaigai@kaigai.gr.jp>
>
>
>
>
> --
> Best regards,
> Sergey Muraviov



-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

Sorry, I've forgotten the report.

The test fails on label test come from specification change in the mcs policy.
Previously, it was applied to all the domains including unconfined_t, but now,
it became to be applied on the domain with "mcsconstrained" attribute.

This regression test run sepgsql_seton() on the system "unconfined_t" domain,
and see the behavior when process intended to move wider or narrower ranged
categories, so it was affected by system policy change, even though it is our
intention of sepgsql.

The attached patch adds "mcsconstrained" attribute on the domain for this
regression test, if this attribute exists. So, it will work on both of F20 and
older system.

Regarding to the regression test on ddl and alter, this change looks to me
hook invocation around recomputeNamespacePath() were gone, because
the schema already allowed to search was already checked.
Is the behavior around recomputeNamespacePath() recently updated?
At least, it is not a matter since {search} permission towards
"regtest_schema_2" is checked in this test scenario.

Thanks,

2014-05-14 13:33 GMT+09:00 Sergey Muraviov <sergey.k.muraviov@gmail.com>:
> Hi.
>
> Some regression tests for sepgsql still not work on Fedora 20:
>
> ============== running regression test queries        ==============
> test label                    ... FAILED
> test dml                      ... ok
> test ddl                      ... FAILED
> test alter                    ... FAILED
> test misc                     ... ok
>
> ======================
>  3 of 5 tests failed.
> ======================
>
> $ sestatus
> SELinux status:                 enabled
> SELinuxfs mount:                /sys/fs/selinux
> SELinux root directory:         /etc/selinux
> Loaded policy name:             targeted
> Current mode:                   enforcing
> Mode from config file:          enforcing
> Policy MLS status:              enabled
> Policy deny_unknown status:     allowed
> Max kernel policy version:      29
>
> $ uname -i -o -r
> 3.14.3-200.fc20.x86_64 x86_64 GNU/Linux
>
> $ /usr/local/pgsql/bin/postgres --version
> postgres (PostgreSQL) 9.4beta1
>
> PS
> I've got this compiler warning:
>  relation.c: In function ‘sepgsql_relation_drop’:
> relation.c:472:25: warning: ‘tclass’ may be used uninitialized in this
> function [-Wmaybe-uninitialized]
>   sepgsql_avc_check_perms(&object,
>                          ^
>
>
> 2013-12-25 0:34 GMT+04:00 Kohei KaiGai <kaigai@kaigai.gr.jp>:
>
>> Hello,
>>
>> It seems to me changes in the base security policy on Fedora affected to
>> the regression test. Our test cases for sepgsql_setcon() utilizes the MCS
>> rules, that prevents domain transition from narrow categories to wider
>> ones,
>> to control the success cases and failure cases.
>>
>> However, its coverage was changed. It was applied all the domains in the
>> system, thus "unconfined_t" domain had been enforced by MCS rules.
>> But now, it shall be applied only domains with "mcs_constrained_type"
>> attribute.
>>
>> [kaigai@vmlinux tmp]$ diff -up old/policy/mcs new/policy/mcs
>>       :
>>  <snip>
>>       :
>>  mlsconstrain process { transition dyntransition }
>> -       (( h1 dom h2 ) or ( t1 == mcssetcats ));
>> +       (( h1 dom h2 ) or ( t1 != mcs_constrained_type ));
>>
>> Probably, we need to define a domain by ourselves for regression test to
>> ensure
>> the test stability, not using the system "unconfined" domain that has
>> different
>> meaning by release.
>>
>> I'll make a patch. Please wait for a while.
>>
>> Thanks for your test & reports.
>>
>> 2013/12/18 Sergey Muraviov <sergey.k.muraviov@gmail.com>:
>> > # semodule -l | grep sepgslq
>> > sepgsql-regtest 1.07
>> >
>> > Full list of modules is in attachment.
>> >
>> >
>> > 2013/12/18 Kohei KaiGai <kaigai@kaigai.gr.jp>
>> >>
>> >> Could you show me semodule -l on your environment?
>> >> I believe security policy has not been changed between F19 and F20...
>> >>
>> >> Thanks,
>> >>
>> >> 2013/12/18 Sergey Muraviov <sergey.k.muraviov@gmail.com>:
>> >> > Hi
>> >> >
>> >> > I've tried to test postgres 9.3.2 and 9.4devel with selinux on Fedora
>> >> > 20
>> >> > and
>> >> > met with a label regression test failure.
>> >> >
>> >> > PS
>> >> > I've got some warning during build process.
>> >> >
>> >> > --
>> >> > Best regards,
>> >> > Sergey Muraviov
>> >> >
>> >> >
>> >> > --
>> >> > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
>> >> > To make changes to your subscription:
>> >> > http://www.postgresql.org/mailpref/pgsql-hackers
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> KaiGai Kohei <kaigai@kaigai.gr.jp>
>> >
>> >
>> >
>> >
>> > --
>> > Best regards,
>> > Sergey Muraviov
>>
>>
>>
>> --
>> KaiGai Kohei <kaigai@kaigai.gr.jp>
>
>
>
>
> --
> Best regards,
> Sergey Muraviov



--
KaiGai Kohei <kaigai@kaigai.gr.jp>

On 05/14/2014 07:33 AM, Sergey Muraviov wrote:
> I've got this compiler warning:
>   relation.c: In function ‘sepgsql_relation_drop’:
> relation.c:472:25: warning: ‘tclass’ may be used uninitialized in this
> function [-Wmaybe-uninitialized]
>    sepgsql_avc_check_perms(&object,
>                           ^

KaiGei, could you take a look at this warning, too? It looks like a 
genuine bug to me, but I'm not sure what we should do there instead.

- Heikki

2014-05-16 16:26 GMT+09:00 Heikki Linnakangas <hlinnakangas@vmware.com>:
> On 05/14/2014 07:33 AM, Sergey Muraviov wrote:
>>
>> I've got this compiler warning:
>>   relation.c: In function ‘sepgsql_relation_drop’:
>> relation.c:472:25: warning: ‘tclass’ may be used uninitialized in this
>> function [-Wmaybe-uninitialized]
>>    sepgsql_avc_check_perms(&object,
>>                           ^
>
> KaiGei, could you take a look at this warning, too? It looks like a genuine
> bug to me, but I'm not sure what we should do there instead.
>
This warning is harmless, because the code path that does not initialize
"tclass" variable (a case when dropped relation is index) never goes to
the code path that references "tclass".
It just checks schema's {remove_name} permission, then jumps to
another code path for index, never backed.

BTW, I could not produce this message in my environment with -Wall.
(Fedora 20, gcc-4.8.2). Is it a newer compiler's wisdom?

Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>