Bug 479286 - Cannot add custom selinux module
Cannot add custom selinux module
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: policycoreutils (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-08 11:39 EST by Orion Poplawski
Modified: 2009-06-26 15:59 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-26 15:59:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Original fips.te (150 bytes, text/plain)
2009-01-13 15:19 EST, Orion Poplawski
no flags Details

  None (edit)
Description Orion Poplawski 2009-01-08 11:39:30 EST
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
Comment 1 Daniel Walsh 2009-01-13 10:39:34 EST
Who created this pp file?  Looks like it was created on a machine with MLS disabled?
Comment 2 Orion Poplawski 2009-01-13 12:07:19 EST
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?
Comment 3 Daniel Walsh 2009-01-13 15:06:25 EST
Do you have the original te file?  Can you recreate it on the latest machine?
Comment 4 Orion Poplawski 2009-01-13 15:19:26 EST
Created attachment 328913 [details]
Original fips.te
Comment 5 Daniel Walsh 2009-01-13 15:59:22 EST
If you use Make to rebuild the pp file will it install?
Comment 6 Orion Poplawski 2009-01-13 16:13:35 EST
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!
Comment 7 Daniel Walsh 2009-01-13 16:49:24 EST
rpm -q selinux-policy
Comment 8 Orion Poplawski 2009-01-13 16:52:26 EST
selinux-policy-3.5.13-38.fc10.noarch
Comment 9 Daniel Walsh 2009-01-14 09:10:11 EST
Stange it works for me.

It has got to be some setup issue,  Adding Steven, since I recall this happening once before.
Comment 10 Stephen Smalley 2009-01-14 09:29:53 EST
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
Comment 11 Orion Poplawski 2009-01-14 10:35:09 EST
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!
Comment 12 Stephen Smalley 2009-01-14 10:48:26 EST
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.

Note You need to log in before you can comment on or make changes to this bug.