Description of problem: Trying to add custom module: # semodule -i fips.pp libsepol.context_from_record: MLS is enabled, but no MLS context found libsepol.context_from_record: could not create context structure libsepol.context_from_string: could not create context structure libsepol.sepol_context_to_sid: could not convert user_u:object_r:user_home_dir_t to sid invalid context user_u:object_r:user_home_dir_t libsemanage.semanage_install_active: setfiles returned error code 1. libsepol.context_from_record: MLS is enabled, but no MLS context found libsepol.context_from_record: could not create context structure libsepol.context_from_string: could not create context structure libsepol.sepol_context_to_sid: could not convert user_u:object_r:user_home_dir_t to sid invalid context user_u:object_r:user_home_dir_t libsemanage.semanage_install_active: setfiles returned error code 1. semodule: Failed! Version-Release number of selected component (if applicable): policycoreutils-2.0.57-14.fc10.i386
Who created this pp file? Looks like it was created on a machine with MLS disabled?
Created with audit2allow on this machine. Machine has been upgraded via yum from 8->9->10 so there could very well be some stuff screwed up. How to check MLS status?
Do you have the original te file? Can you recreate it on the latest machine?
Created attachment 328913 [details] Original fips.te
If you use Make to rebuild the pp file will it install?
Nope. # make -f /usr/share/selinux/devel/Makefile fips.pp Compiling targeted fips module /usr/bin/checkmodule: loading policy configuration from tmp/fips.tmp /usr/bin/checkmodule: policy configuration loaded /usr/bin/checkmodule: writing binary representation (version 8) to tmp/fips.mod Creating targeted fips.pp policy package rm tmp/fips.mod tmp/fips.mod.fc [root@saga ~]# semodule -i fips.pp libsepol.context_from_record: MLS is enabled, but no MLS context found ...... semodule: Failed!
rpm -q selinux-policy
selinux-policy-3.5.13-38.fc10.noarch
Stange it works for me. It has got to be some setup issue, Adding Steven, since I recall this happening once before.
The error is an invalid context, which means that somewhere you have a file contexts entry that lacks a :s0 suffix. As you don't seem to have a fips.fc file (or do you?), I'd assume you have an already invalid policy store and this only gets noticed when you go to update it by inserting this other module, not that this module has anything to do with it. On a F10 system here: $ cd /etc/selinux/targeted/modules/active $ grep user_home_dir_t file_contexts* file_contexts.homedirs:/home/[^/]* -d system_u:object_r:user_home_dir_t:s0 file_contexts.homedirs:/home/[^/]* -l system_u:object_r:user_home_dir_t:s0 file_contexts.template:HOME_DIR -d system_u:object_r:user_home_dir_t:s0 file_contexts.template:HOME_DIR -l system_u:object_r:user_home_dir_t:s0 Note that they all have system_u, not user_u, and that they all have a :s0 suffix. BTW, if you did an upgrade from F8, you should check your semanage login -l output and semanage user -l output. On a clean F10 install, I get: $ semanage login -l Login Name SELinux User MLS/MCS Range __default__ unconfined_u s0 root unconfined_u s0-s0:c0.c1023 system_u system_u s0-s0:c0.c1023 $ semanage user -l # semanage user -l Labeling MLS/ MLS/ SELinux User Prefix MCS Level MCS Range SELinux Roles guest_u user s0 s0 guest_r root user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r staff_u user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r sysadm_u user s0 s0-s0:c0.c1023 sysadm_r system_u user s0 s0-s0:c0.c1023 system_r unconfined_u user s0 s0-s0:c0.c1023 system_r unconfined_r user_u user s0 s0 user_r xguest_u user s0 s0 xguest_r
That's the ticket. I have some local policy in /etc/selinux/targeted/contexts/files/file_contexts.local that did not have :s0 at the end. After adding the :s0 I could load the module. Is there some way this could have (should have?) been handled during an upgrade? In this case I'm using yum instead of anaconda, but if the is a command that would have made the change or would I have had the same trouble using anaconda? As for the other stuff: # semanage login -l Login Name SELinux User MLS/MCS Range __default__ unconfined_u s0-s0:c0.c1023 root root s0-s0:c0.c255 system_u system_u s0-s0:c0.c1023 # semanage user -l Labeling MLS/ MLS/ SELinux User Prefix MCS Level MCS Range SELinux Roles root user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r staff_u user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r sysadm_u user s0 s0-s0:c0.c1023 sysadm_r system_u user s0 s0-s0:c0.c1023 system_r unconfined_u unconfined s0 s0-s0:c0.c1023 system_r unconfined_r user_u user s0 s0 user_r Where does this stuff get set? Thanks!
The real question is how did it get added in the first place without triggering an error (did you add the entry perhaps when SELinux was disabled and thus it couldn't tell whether MLS was enabled, or how did you go about adding it?), and why didn't it trigger when you were performing the update and it tried to update the policy package. No errors at all upon the yum update or in yum.log? The login (Linux user) data is maintained in the seusers file. $ cd /etc/selinux/targeted/modules/active $ cat seusers # This file is auto-generated by libsemanage # Do not edit directly. system_u:system_u:s0-s0:c0.c1023 root:unconfined_u:s0-s0:c0.c1023 __default__:unconfined_u:s0 Although you aren't supposed to directly edit it, you can do so and then run semodule -B to force a rebuild of the policy to update to it. Or you can use semanage login -m or system-config-selinux to modify it the "proper" way. The user (SELinux user) data comes from the policy modules.