Description of problem: Version-Release number of selected component (if applicable): How reproducible: Only have done one machine so far. Steps to Reproduce: upgraded from 8 current yum to 9 via net afterwards found out I could not log into the system. GUI login locked text login simply returned to login SSH login gave security error for bash. no error messages in logs. Checked other things and suspected selinux. prior to upgrade I was running permissive. It seems to have switched me to strict. Switching back to permissive gives the following error message May 24 13:49:28 railyard setroubleshoot: SELinux is preventing the bash from using potentially mislabeled files (./.bash_profile). For complete SELinux messages. run sealert -l f743b1e5-fe8e-43f3-8f4d-462110fbc679 I see several issues here. #1 upgrading is supposed to not break things #2 selinux should be putting out error messages for this when in strict mode #3 It should not have switched us
Can you boot in permissive mode and attach the /var/log/audit/audit.log
Created attachment 306798 [details] the file you wanted Already in this mode. Was in this mode before the upgrade. Some of my software doesn't like sellinux and I have not gotten to fixing it. One of the problems is that somehow the upgrade switched the config file to enforcing and strict from permissive and targeted which is what it is now and what it was before the upgrade.
If you execute # fixfiles restore and then reboot can you login?
Well switching to permissive mode fixed the problem with the logins. But still am getting the messages regarding bash. Will let you know if this fixes it.
Did it --- no joy. var log messages still has messages like this May 27 22:08:03 railyard setroubleshoot: SELinux is preventing the bash from using potentially mislabeled files (/root/.bash_profile). For complete SELinux messages. run sealert -l 6b31c4e1-d6e1-4be0-a60f-2a58d98a1c4f Incidentally all .bash_profiles seem to be "misslabeled"
# semodule login -l # semodule user -l
I take it you want me to run these? Should I then reboot and try it again or print out something and send it back to you or something?
Yes run these no reboot necessary. These will just show me if you user database is setup correctly.
OK and I think the answer is no they are not given what I see here. su - Password: [root@railyard ~]# semodule login -l unknown additional arguments: login usage: semodule [options]... MODE [MODES]... Manage SELinux policy modules. MODES: -R, --reload reload policy -B, --build build and reload policy -i,--install=MODULE_PKG install a new module -u,--upgrade=MODULE_PKG upgrade existing module -b,--base=MODULE_PKG install new base module -r,--remove=MODULE_NAME remove existing module -l,--list-modules display list of installed modules Other options: -s,--store name of the store to operate on -n,--noreload do not reload policy after commit -h,--help print this message and quit -v,--verbose be verbose -D,--disable_dontaudit Remove dontaudits from policy [root@railyard ~]# semodule user -l unknown additional arguments: user usage: semodule [options]... MODE [MODES]... Manage SELinux policy modules. MODES: -R, --reload reload policy -B, --build build and reload policy -i,--install=MODULE_PKG install a new module -u,--upgrade=MODULE_PKG upgrade existing module -b,--base=MODULE_PKG install new base module -r,--remove=MODULE_NAME remove existing module -l,--list-modules display list of installed modules Other options: -s,--store name of the store to operate on -n,--noreload do not reload policy after commit -h,--help print this message and quit -v,--verbose be verbose -D,--disable_dontaudit Remove dontaudits from policy
Sorry too early in the morning I guess semanage login -l semanage user -l
This at least looks like something other than error messages. su - Password: [root@railyard ~]# semanage login -l Login Name SELinux User MLS/MCS Range __default__ system_u s0 root system_u s0-s0:c0.c1023 system_u system_u s0-s0:c0.c1023 [root@railyard ~]# semanage user -l Labeling MLS/ MLS/ SELinux User Prefix MCS Level MCS Range SELinux Roles guest_u guest s0 s0 guest_r root user s0 s0-s0:c0.c1023 system_r staff_r unconfined_r sysadm_r staff_u user s0 s0-s0:c0.c1023 system_r staff_r sysadm_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 system_r unconfined_r user_u user s0 s0 user_r xguest_u xguest s0 s0 xguest_r
Execute # semanage login -m -S targeted -s "unconfined_u" -r s0-s0:c0.c1023 __default__ # semanage login -m -S targeted -s "unconfined_u" -r s0-s0:c0.c1023 root Which should set you up to login with the correct context.
Now this is interesting. Maybe we have found the problem??? semanage login -m -S targeted -s "unconfined_u" -r s0-s0:c0.c1023 __default__ libsemanage.validate_handler: MLS range s0-s0:c0.c1023 for Unix user __default__ exceeds allowed range s0 for SELinux user unconfined_u (No such file or directory). libsemanage.validate_handler: seuser mapping [__default__ -> (unconfined_u, s0-s0:c0.c1023)] is invalid (No such file or directory). libsemanage.dbase_llist_iterate: could not iterate over records (No such file or directory). /usr/sbin/semanage: Could not modify login mapping for __default__ [root@railyard ~]# semanage login -m -S targeted -s "unconfined_u" -r s0-s0:c0.c1023 root libsemanage.validate_handler: MLS range s0-s0:c0.c1023 for Unix user root exceeds allowed range s0 for SELinux user unconfined_u (No such file or directory). libsemanage.validate_handler: seuser mapping [root -> (unconfined_u, s0-s0:c0.c1023)] is invalid (No such file or directory). libsemanage.dbase_llist_iterate: could not iterate over records (No such file or directory). /usr/sbin/semanage: Could not modify login mapping for root
No, You need to execute I did not notice this the first time # semanage user -m -r s0-s0:c0.c1023 unconfined_u # semanage login -m -S targeted -s "unconfined_u" -r s0-s0:c0.c1023 __default__ # semanage login -m -S targeted -s "unconfined_u" -r s0-s0:c0.c1023 root
OK this time it seems to have executed properly, or at least without error messages. Looks like it fixed the problem, now the real question, why did it happen in the first place? Also why did the upgrade switch the config file to the most restrict settings?
Yes the post install scripts of selinux-policy is supposed to execute the commands I gave you to fix the user database. But what do you mean switch to the config file?
Interesting, wonder why it didn't. The other thing that happened was that the /etc/selinux/config file which was originally over ridden to be permissive and targeted had those values switched to enforcing and strict.
I can't see how this could apply, but I supposed the yum I did before the upgrade could have done something. Basically I have a backup of the time about 4 hours before I started the process and it was permissive and targeted. Then the system ran until I started the upgrade process. To do the upgrade I first ran yum on the fc8 system and upgraded to the current set. Then I did an over the net install from a net install cd. Then rebooted and waited about an hour. (I was also doing some other processes on other servers and was paying more attention to them) Noticed that some of my processes were not passing nagios check diagnostics. I was able to ping the server. Then started to try and log in and had the hangs and errors mentioned above start happening. Had to go into single user mode several times to find the problem. Interestingly nothing was also going into the log files. Once I found the problem I double checked and that last backup I mentioned had the right structure on the config file. I switched the config file back to the permissive and targetted modes and found everything started working again. But I was getting these bash errors and so filled out a bug report.
Well strict policy does not exist on Fedora 9 so I don't know how your config file would have changed to strict. Anaconda/rpm might have fooled selinux-policy package to think it was not installed and therefor changed the machine to the default of enforcing, but I have never seen this before. The user database is supposed to be fixed by a rpm trigger. Basically the package is looking at the current version of selinux-policy and if it is less then a certain version, it is supposed to execute a script to update the user database. We have checked this out with yum update, but It might blow up using the metho you are using.
Does seem strange. However, the yum update to the latest versions before doing the upgrade is the recommended procedure. However, I have noticed that this in the past seemed to break things. Frequently the versions of the old packages seem to some times be newer than the versions of the packages on the new OS and therefore don't get upgraded. Worse so times only one or two in a group of related packages will get upgraded when they need to be upgraded together. Someone might want to reconsider this recommendation.
OK I have a second machine that did this. Interestingly enough I think I watched it goof. Doing a preupgrade install. It got to the selinux targeted policy thing. This took an extraordinary amount of time. (about 10 minutes) Then there was some kind of what appeared to be a flashed error message on the screen. Something about retrying --- I think, but it was up for 1 maybe 2 seconds :-( Then it went on with the install Does this bring anything to mind?
Well the incredible amount of time is caused by the package relabeling large portions of your file system. Major labeling changes between F8 and F9 require most of the system to be relabeled. Look in /root and see if there is a log file?
There is an install.log but it doesn't show any errors. It just shows the rpm being loaded. Would it be possible that it needs to access something out of the internet during or at the end of this process. I experienced an overload on the mirror which was used for the install so some of the other machines. Basically it was returning the to many users thing. Could the problem be that the rpm is tring to get some more files, and fails and then just exits?
Here is the code %triggerpostun targeted -- selinux-policy-targeted < 3.2.5-9.fc9 . /etc/selinux/config [ "${SELINUXTYPE}" != "targeted" ] && exit 0 setsebool -P use_nfs_home_dirs=1 semanage user -l | grep -s unconfined_u if [ $? -eq 0 ]; then semanage user -m -R "unconfined_r system_r" -r s0-s0:c0.c1023 unconfined_u 2> /dev/null else semanage user -a -P user -R "unconfined_r system_r" -r s0-s0:c0.c1023 unconfined_u 2> /dev/null fi seuser=`semanage login -l | grep __default__ | awk '{ print $2 }'` [ "$seuser" != "unconfined_u" ] && semanage login -m -s "unconfined_u" -r s0-s0:c0.c1023 __default__ seuser=`semanage login -l | grep root | awk '{ print $2 }'` [ "$seuser" == "system_u" ] && semanage login -m -s "unconfined_u" -r s0-s0:c0.c1023 root restorecon -R /root /etc/selinux/targeted 2> /dev/null semodule -r qmail 2> /dev/null exit 0 So if the policy is not targeted or you had a policy >= 3.2.5-9.fc9 This would not fire. Jeremy do you have any ideas?
I found that the two semanage commands did the trick for me after an upgrade from fedora 8 to fedora 9. I also had to rerun these commands after a recent yum upgrade upgraded selinux. Rerunning these commands fixed a problem I had with automounting CDs and DVDs. #fix dvd automount boot with selinux=0 boot with selinux enabled #forces relabel setenforce 0 semanage login -m -S targeted -s "unconfined_u" -r s0-s0:c0.c1023 __default__ semanage login -m -S targeted -s "unconfined_u" -r s0-s0:c0.c1023 root reboot # insert a dvd and automount works fine