Bug 623514
Summary: | After yum update, system cannot boot without selinux=0 kernel parameter | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Reartes Guillermo <rtguille> | ||||
Component: | selinux-policy | Assignee: | Daniel Walsh <dwalsh> | ||||
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | urgent | Docs Contact: | |||||
Priority: | low | ||||||
Version: | 13 | CC: | dwalsh, mgrepl | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2010-08-16 14:03:23 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Reartes Guillermo
2010-08-12 01:47:56 UTC
Reartes, could you try to edit /etc/selinux/config and change the field SELINUX=enforcing to SELINUX=permissive After that execute: # touch /.autorelabel; reboot It works! Great Advice! edited /etc/selinux/config and change the field SELINUX=enforcing to SELINUX=permissive After that executed: # touch /.autorelabel; reboot I am able to boot with selinux enabled (but permissive) -------------------------------------------------------------- # setenforce enforcing After that, the process dbus-daemon gets constant 23% cpu usage and disk access (that was the process with strange behaviour i noticed after yum uptate). # setenforce permissive The process dbus-daemon returns to normal? but the issue returns. So i repeated the fix and left it in permissive for now. After the relabel, did you see any AVC messages in /var/log/audit/audit.log? Yes, there are quite a lot actually... I will create an attachment. Created attachment 438569 [details]
audit.log after relabeling with AVC
/var/log/audit/audit.log
Right after executing the autorelabel stuff.
What says matchpathcon /lib64/libc-2.12.so This looks like an old bug where restorecond would go wild relabeling everything as admin_home_t. Could you make sure the restorecond service is not running. Also did you login an X Session as root? # matchpathcon /lib64/libc-2.12.so /lib64/libc-2.12.so system_u:object:lib_t:s0 restorecond is off in all runlevels and it is not running. I logged as a normal user (but used su - to execute privileged commands) I tried again # setenforce enforcing (under normal user via su -) These processes where the ones with more cpu utilization. dbus-daemon ksmtuned After issuing the command, i lost 'the keyboard' (this is the second time it happened in a month, after issuing a command wich resulted in high load). Unpluggin and repluggin the keyboard does not work (maybe another separate issue to troubleshout), no caps lock... ssh is closed, forgot to enable after last reinstall... :-( Hummm... The relabeling process complained over some conflict, it seems it choose admin_t for some files... [root@ulquiorra /]# ls -lZ /lib64/libc-2.12.so -rwxr-xr-x. root root system_u:object_r:admin_home_t:s0 /lib64/libc-2.12.so [root@ulquiorra /]# restorecon /lib64/libc-2.12.so [root@ulquiorra /]# ls -lZ /lib64/libc-2.12.so -rwxr-xr-x. root root system_u:object_r:lib_t:s0 /lib64/libc-2.12.so [root@ulquiorra /]# cd /lib64 [root@ulquiorra lib64]# ls -lZ|grep home_ -rwxr-xr-x. root root system_u:object_r:admin_home_t:s0 ld-2.12.so -rwxr-xr-x. root root system_u:object_r:admin_home_t:s0 libasound.so.2.0.0 -rwxr-xr-x. root root system_u:object_r:admin_home_t:s0 libglib-2.0.so.0.2400.1 -rwxr-xr-x. root root system_u:object_r:admin_home_t:s0 libgthread-2.0.so.0.2400.1 -rwxr-xr-x. root root system_u:object_r:admin_home_t:s0 libm-2.12.so -rwxr-xr-x. root root system_u:object_r:admin_home_t:s0 libpthread-2.12.so -rwxr-xr-x. root root system_u:object_r:admin_home_t:s0 librt-2.12.so -rwxr-xr-x. root root system_u:object_r:admin_home_t:s0 libudev.so.0.6.1 [root@ulquiorra lib64]# restorecon /lib64/ld-2.12.so [root@ulquiorra lib64]# restorecon /lib64/libasound.so.2 [root@ulquiorra lib64]# restorecon /lib64/libgthread-2.0.so.0 [root@ulquiorra lib64]# restorecon /lib64/libm-2.12.so [root@ulquiorra lib64]# restorecon /lib64/libpthread-2.12.so [root@ulquiorra lib64]# restorecon /lib64/librt-2.12.so [root@ulquiorra lib64]# restorecon /lib64/libudev.so.0 [root@ulquiorra lib64]# ls -lZ|grep home_ -rwxr-xr-x. root root system_u:object_r:admin_home_t:s0 libglib-2.0.so.0.2400.1 [root@ulquiorra lib64]# restorecon /lib64/libglib-2.0.so.0.2400.1 [root@ulquiorra lib64]# ls -lZ|grep home_ [root@ulquiorra lib64]# ls /lib -lZ|grep home_ [root@ulquiorra lib64]# ls /bin -lZ|grep home_ -rwxr-xr-x. root root system_u:object_r:admin_home_t:s0 bash [root@ulquiorra lib64]# restorecon /bin/bash [root@ulquiorra lib64]# ls /bin -lZ|grep home_ [root@ulquiorra lib64]# ls /sbin -lZ|grep home_ [root@ulquiorra lib64]# ls /usr/sbin -lZ|grep home_ [root@ulquiorra lib64]# ls /usr/bin -lZ|grep home_ [root@ulquiorra lib64]# ls /usr/lib -lZ|grep home_ [root@ulquiorra lib64]# ls /usr/lib64/ -lZ|grep home_ [root@ulquiorra lib64]# ls /usr/libexec/ -lZ|grep home_ [root@ulquiorra lib64]# ls /etc -lZ|grep home_ Are you able to boot without errors now? Also what says grep -r admin_home_t /etc/selinux/targeted/contexts/ I found this AVC, currently the only one reported by the selinux-gui-utility. ----------------------- Summary: SELinux is preventing /bin/bash access to a leaked /root file descriptor. Detailed Description: [SELinux is in permissive mode. This access was not denied.] SELinux denied access requested by the prelink command. It looks like this is either a leaked descriptor or prelink output was redirected to a file it is not allowed to access. Leaks usually can be ignored since SELinux is just closing the leak and reporting the error. The application does not use the descriptor, so it will run properly. If this is a redirection, you will not get output in the /root. You should generate a bugzilla on selinux-policy, and it will get routed to the appropriate package. You can safely ignore this avc. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Additional Information: Source Context system_u:system_r:prelink_cron_system_t:s0-s0:c0.c 1023 Target Context system_u:object_r:admin_home_t:s0 Target Objects /root [ dir ] Source prelink Source Path /bin/bash Port <Unknown> Host ulquiorra.espada Source RPM Packages bash-4.1.7-1.fc13 Target RPM Packages filesystem-2.4.31-1.fc13 Policy RPM selinux-policy-3.7.19-44.fc13 Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Plugin Name leaks Host Name ulquiorra.espada Platform Linux ulquiorra.espada 2.6.34.3-37.fc13.x86_64 #1 SMP Tue Aug 10 21:09:58 UTC 2010 x86_64 x86_64 Alert Count 1 First Seen Mon 16 Aug 2010 03:20:57 AM ART Last Seen Mon 16 Aug 2010 03:20:57 AM ART Local ID 3717d61a-b04e-4281-b83e-5f3393016ed7 Line Numbers Raw Audit Messages node=ulquiorra.espada type=AVC msg=audit(1281939657.156:24190): avc: denied { read } for pid=5101 comm="prelink" path="/root" dev=sda3 ino=742 scontext=system_u:system_r:prelink_cron_system_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=dir node=ulquiorra.espada type=SYSCALL msg=audit(1281939657.156:24190): arch=c000003e syscall=59 success=yes exit=0 a0=1e69860 a1=1e69ff0 a2=1e69530 a3=10 items=0 ppid=4926 pid=5101 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=27 comm="prelink" exe="/bin/bash" subj=system_u:system_r:prelink_cron_system_t:s0-s0:c0.c1023 key=(null) ------------------------------- Since it said something about prelink (don't really know much about it). # prelink -af And now i will try to set selinux in enforcing # setenforce=enforcing The dbus-daemon issue didn't ocurr, now... so i set it to enforcing in /etc/selinux/config # init 6 WOW! It WORKS. Currently im able to boot with selinux enabled & enforcing :-) Thanks for the help and advices. Guillermo. ------------------------------------------ Update: [root@ulquiorra ~]# grep -r admin_home_t /etc/selinux/targeted/contexts/ /etc/selinux/targeted/contexts/files/file_contexts:/root(/.*)? system_u:object_r:admin_home_t:s0 (In reply to comment #11) > I found this AVC, currently the only one reported by the selinux-gui-utility. > This is a different issue which is caused by cronie. We added a fix to selinux-policy-3.7.19-47.fc13.noarch. This update should be available from update repo now. > Update: > > [root@ulquiorra ~]# grep -r admin_home_t /etc/selinux/targeted/contexts/ > /etc/selinux/targeted/contexts/files/file_contexts:/root(/.*)? > system_u:object_r:admin_home_t:s0 Looks good. Please reopen if it happens again. |