Hello Stephen,
thanks again for your reply.
Switching from non-MCS policy to MCS policy works after I followed your advice of renaming the policy, although it does not make much sense to me...
I don't understand why it only does work when I change name to the policy (as if it can't just overwrite the existing one) ! Perhaps, we should document it somewhere in the manual page for load_policy and semodule or otherwise in the README file of the reference policy ?
Anyhow, that's sorted out now and the system correctly booted into the MCS policy.
Best regards,
Guido Trentalancia
On Tue, 2010-01-26 at 16:02 +0100, Guido Trentalancia wrote:
> Hello Stephen,
>
> thanks again for your reply.
>
> Switching from non-MCS policy to MCS policy works after I followed your advice of renaming the policy, although it does not make much sense to me...
>
> I don't understand why it only does work when I change name to the policy (as if it can't just overwrite the existing one) ! Perhaps, we should document it somewhere in the manual page for load_policy and semodule or otherwise in the README file of the reference policy ?
>
> Anyhow, that's sorted out now and the system correctly booted into the MCS policy.
If libsemanage encounters an error at any point during the update
transaction, it rolls back to the previous policy as a safety measure so
that your system will still have a known working policy in place. So
when it failed to load the MCS policy into the kernel, it performed the
rollback.
Using a different store name disables automatic loading of the policy
since it isn't your active policy store (as defined by
your /etc/selinux/config), and thus avoids the problem. The other
solution would have been to pass -n to semodule to disable automatic
loading of the new policy.
--
Stephen Smalley
National Security Agency