Description of problem: When using useradd -Z the context of seusers and the policy file are set to SystemLow. # fixfiles check /etc/selinux/ /sbin/restorecon reset /etc/selinux/mls/seusers context staff_u:object_r:selinux_config_t:s0->system_u:object_r:selinux_config_t:s15:c0.c1023 /sbin/restorecon reset /etc/selinux/mls/policy/policy.21 context staff_u:object_r:policy_config_t:s0->system_u:object_r:policy_config_t:s15:c0.c1023 Version-Release number of selected component (if applicable): shadow-utils-4.0.17-12.el5 selinux-policy-2.4.6-67.el5 How reproducible: Everytime, even when selecting what would be the default SELinux user. Steps to Reproduce: 1. useradd -Z user_u alice 2. fixfiles check /etc/selinux Actual results: The policy file and the seusers file gets relabeled to SystemLow from SystemHigh Expected results: The file should remain at the correct level. Additional info: It seems that you can only run useradd from SystemLow, otherwise you are unable to lock the password file [root/sysadm_r/SystemHigh@cert-i5 root]# useradd -Z staff_u -n bob useradd: unable to lock password file As a result these trusted databases are set to SystemLow.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Fixed in selinux-policy-2.4.6-69
This bug is not critical as far as LSPP compliance is concerned - the seusers and policy files do not contain any information that specifically needs to be at SystemHigh. As long as the changed level doesn't actually break applications it's not urgent to fix.
The changed level does break applications. Once the files are relabeled SystemHigh subsequent operations on them fail, useradd -Z, semanage, anything else that needs access to that database. This can be worked around by running `fixfiles restore /etc/selinux` after each time the database gets relabel to the wrong level, but otherwise the second time you run anything it will fail due to the MLS level being incorrect.
What was the policy change? Was it to make seusers SystemLow by default? If the passwd file is SystemLow then it seems seusers could be as well. Any idea why running semanage to update seusers doesn't have the same issue?
Turns out this is a problem with semanage also. When updating the system. semanage will lower the sensitivity of the seusers and policy.21 file So this is really a libsemanage problem. Reassiging
We agreed to change the sensitivity level of seusers and policy.21 to SystemLow on the phone. Fixed in selinux-policy-2.4.6-71
A fix for this issue has been included in the packages contained in the beta (RHN channel) or most recent snapshot (partners.redhat.com) for RHEL5.1. Please verify that your issue is fixed. After you (Red Hat Partner) have verified that this issue has been addressed, please perform the following: 1) Change the *status* of this bug to VERIFIED. 2) Add *keyword* of PartnerVerified (leaving the existing keywords unmodified) If this issue is not fixed, please add a comment describing the most recent symptoms of the problem you are having and change the status of the bug to ASSIGNED.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2007-0544.html