-
Notifications
You must be signed in to change notification settings - Fork 139
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Policy fails to build due to unconfined role move #829
Comments
I also encountered this issue. |
First, we need to fix the discrepancy between the two SELinux userspace behaviors. Then we can update refpolicy, if necessary. cc @jwcart2 |
I am not sure what is going on here. Roles most definitely can be in modules. It looks like a problem converting the module pp file to CIL (creating a roletype rule instead of a role), but I have test policy which has roles in modules and pp converted them to CIL just fine. I will investigate. |
I found the issue. It is in module_to_cil.c. It will not create user_r, staff_r, sysadm_r, system_r, or unconfined_r, so that duplicate role definitions are not created. I can remove unconfined_r from the list in module_to_cil.c, but I am worried that that would break other policies. |
Each project's special case behavior is co-dependent on each other, making this a difficult cycle to break. I see the options as:
|
We already allow types and type attributes to have duplicates if the multiple_decls field is set by calling cil_set_multiple_decls(). In secilc, this happens when you use the "-m" command-line option. I could remove unconfined_r from the list in module_to_cil.c, allow multiple roles in CIL when the multiple_decls field is set, and change libsemanage to always call cil_set_multiple_decls() before calling cil_compile(). This should prevent problems with previous policies. Allowing multiple decls should be harmless. |
I sent a patch series to the SELinux list which will fix this. |
There have been some discrepancies between semodule_link/_expand and semodule -i, see SELinuxProject#829. Add an extra CI test of installing the modules using semodule -i. Signed-off-by: Chris PeBenito <[email protected]>
There have been some discrepancies between semodule_link/_expand and semodule -i, see SELinuxProject#829. Add an extra CI test of installing the modules using semodule -i. Signed-off-by: Chris PeBenito <[email protected]>
There have been some discrepancies between semodule_link/_expand and semodule -i, see SELinuxProject#829. Add an extra CI test of installing the modules using semodule -i. Signed-off-by: Chris PeBenito <[email protected]>
There have been some discrepancies between semodule_link/_expand and semodule -i, see SELinuxProject#829. Add an extra CI test of installing the modules using semodule -i. Signed-off-by: Chris PeBenito <[email protected]>
There have been some discrepancies between semodule_link/_expand and semodule -i, see SELinuxProject#829. Add an extra CI test of installing the modules using semodule -i. Signed-off-by: Chris PeBenito <[email protected]>
There have been some discrepancies between semodule_link/_expand and semodule -i, see SELinuxProject#829. Add an extra CI test of installing the modules using semodule -i. Signed-off-by: Chris PeBenito <[email protected]>
There have been some discrepancies between semodule_link/_expand and semodule -i, see SELinuxProject#829. Add an extra CI test of installing the modules using semodule -i. Signed-off-by: Chris PeBenito <[email protected]>
Commit ca3698d changed the definition of the
unconfined_r
role from the base module kernel to the non-base module unconfined.While directly linking the policy via
make validate
works, loading such policy on an actual systems fails with the following error message:I don't think role definitions are supported in non-base modular policies (only role statements associating them to types).
The text was updated successfully, but these errors were encountered: