Hi Paul,
Enlightened by a similar issue(https://partner-bugzilla.redhat.com/show_bug.cgi?id=607912) I seems to find the root cause for the below failure when trying to inserting the lspp_test.pp from the latest audit-test-2177 version to the SELinux policy generated from refpolicy-2.20091117:
[root/secadm_r/s0 at qemu-host selinux-policy]# semodule -i lspp_test.pp
libsepol.expand_terule_helper: conflicting TE rule for (lspp_test_generic_t, sepgsql_db_t:db_table): old was user_sepgsql_table_t, new is sepgsql_table_t
libsepol.expand_module: Error during expand
libsemanage.semanage_expand_sandbox: Expand module failed
semodule: Failed!
[root/secadm_r/s0 at qemu-host selinux-policy]#
I guess there is a bug in the implementation of postgresql.te in current refpolicy source code, the lspp_test_generic_t domains should not be created by the userdom_unpriv_user_template() template, because the postgresql_role() interface is called by the userdom_unpriv_user_template() template:
userdom_unpriv_user_template(lspp_test_generic)
> postgresql_role($1_r,$1_t):
typeattribute $2 sepgsql_client_type;
allow $2 user_sepgsql_table_t:db_table { getattr use select update insert delete lock };
Which grants the lspp_test_generic_t domain some permissions on the user_sepgsql_table_t type of file of the db_table class.
However, please note that the postgresql_role() interface also adds the lspp_test_generic_t domain into the sepgsql_client_type attribute, which will be granted the same permissions as above on the sepgsql_table_t type of file of the db_table class:
services/postgresql.te:
allow sepgsql_client_type sepgsql_table_t:db_table { getattr use select update insert delete lock };
Which will make the lspp_test.pp unable to be inserted:
libsepol.expand_terule_helper: conflicting TE rule for (lspp_test_generic_t, sepgsql_db_t:db_table): old was user_sepgsql_table_t, new is sepgsql_table_t
In the error message above, the "old" refers to the allow rule presented in the lspp_test.pp:
allow lspp_test_generic_t user_sepgsql_table_t:db_table ...
whereas the "new" refers to the allow rule presented by the postgresql.pp installed into the current SELinux policy:
allow lspp_test_generic_t sepgsql_table_t:db_table ...
So far this problem could be workaround by creating the lspp_test_* domains by the userdom_admin_user_template() template, which won't call the interface of postgresql_role(). Since the lspp_test.pp will be used only when running the test cases provided by the audit-test package to aid CAPP/LSPP certification and easily removed from the SELinux policy store thereafter, this won't diminish the security provided by SELinux.
What do you think?
Thanks,
Harry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20100819/da1d5317/attachment.html
On Thu, 2010-08-19 at 12:37 +0000, TaurusHarry wrote:
> Hi Paul,
>
> Enlightened by a similar
> issue(https://partner-bugzilla.redhat.com/show_bug.cgi?id=607912) I
> seems to find the root cause for the below failure when trying to
> inserting the lspp_test.pp from the latest audit-test-2177 version to
> the SELinux policy generated from refpolicy-2.20091117:
>
> [root/secadm_r/s0 at qemu-host selinux-policy]# semodule -i lspp_test.pp
> libsepol.expand_terule_helper: conflicting TE rule for
> (lspp_test_generic_t, sepgsql_db_t:db_table): old was
> user_sepgsql_table_t, new is sepgsql_table_t
> libsepol.expand_module: Error during expand
> libsemanage.semanage_expand_sandbox: Expand module failed
> semodule: Failed!
> [root/secadm_r/s0 at qemu-host selinux-policy]#
>
> I guess there is a bug in the implementation of postgresql.te in
> current refpolicy source code, the lspp_test_generic_t domains should
> not be created by the userdom_unpriv_user_template() template, because
> the postgresql_role() interface is called by the userdom_unpriv_u
> ser_template() template:
>
> userdom_unpriv_user_template(lspp_test_generic)
> > postgresql_role($1_r,$1_t):
> typeattribute $2 sepgsql_client_type;
> allow $2 user_sepgsql_table_t:db_table { getattr use
> select update insert delete lock };
>
> Which grants the lspp_test_generic_t domain some permissions on the
> user_sepgsql_table_t type of file of the db_table class.
>
> However, please note that the postgresql_role() interface also adds
> the lspp_test_generic_t domain into the sepgsql_client_type attribute,
> which will be granted the same permissions as above on the
> sepgsql_table_t type of file of the db_table class:
>
> services/postgresql.te:
> allow sepgsql_client_type sepgsql_table_t:db_table { getattr use
> select update insert delete lock };
>
> Which will make the lspp _test.pp unable to be inserted:
> libsepol.expand_terule_helper: conflicting TE rule for
> (lspp_test_generic_t, sepgsql_db_t:db_table): old was
> user_sepgsql_table_t, new is sepgsql_table_t
>
> In the error message above, the "old" refers to the allow rule
> presented in the lspp_test.pp:
> allow lspp_test_generic_t user_sepgsql_table_t:db_table ...
> whereas the "new" refers to the allow rule presented by the
> postgresql.pp installed into the current SELinux policy:
> allow lspp_test_generic_t sepgsql_table_t:db_table ...
>
> So far this problem could be workaround by creating the lspp_test_*
> domains by the userdom_admin_user_template() template, which won't
> call the interface of postgresql_role(). Since the lspp_test.pp will
> be used only when running the test cases provided by the audit-test
> package to aid CAPP/LSPP certification and easily removed from the
> SELinux policy store thereafter, this won't diminish the security
> provided by SELinux.
Do you have a patch you could share? It is always easier to evaluate an
idea when you have the changes to look at ...
--
paul moore
linux @ hp