Bug 728409

Summary: selinux freezing boot
Product: [Fedora] Fedora Reporter: Bill C. Riemers <briemers>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 15CC: dominick.grift, 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: 2011-10-07 14:56:05 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:

Description Bill C. Riemers 2011-08-05 02:41:21 UTC
Description of problem:

Starting today after a yum update my laptop was refusing to boot.   It would just hang near the final stage.  After examining the logs, I found it was freezing in avahi-deamon.service, and also pcscd.service was failing to start.

After disabling the service, I was able to startup, but I could not login via gdm, as the greeter would freeze before displaying any users.   I could however login via a text console.  There errors in the gdm log were non-informative:

GConf Error: Failed to contact configuration server; the most common cause is a 
missing or misconfigured D-Bus session bus daemon. See http://projects.gnome.org
/gconf/ for information. (Details -  1: GetIOR failed: GDBus.Error:org.freedeskt
op.DBus.Error.ServiceUnknown: The name org.gnome.GConf was not provided by any .
service files)
GConf Error: Failed to contact configuration server; the most common cause is a 
missing or misconfigured D-Bus session bus daemon. See http://projects.gnome.org
/gconf/ for information. (Details -  1: GetIOR failed: GDBus.Error:org.freedeskt
op.DBus.Error.ServiceUnknown: The name org.gnome.GConf was not provided by any .
service files)
GConf Error: Failed to contact configuration server; the most common cause is a 
missing or misconfigured D-Bus session bus daemon. See http://projects.gnome.org
/gconf/ for information. (Details -  1: GetIOR failed: GDBus.Error:org.freedeskt
op.DBus.Error.ServiceUnknown: The name org.gnome.GConf was not provided by any .
service files)
GConf Error: Failed to contact configuration server; the most common cause is a 
missing or misconfigured D-Bus session bus daemon. See http://projects.gnome.org
/gconf/ for information. (Details -  1: GetIOR failed: GDBus.Error:org.freedeskt
op.DBus.Error.ServiceUnknown: The name org.gnome.GConf was not provided by any .
service files)

However, on a hunch after spending hours trying other fixes,  I changed selinux from enforcing to permissive.   Now everything is starting normally.   I'm not seeing anything in sealerts.  So I really have no idea why enforce mode in freezing my laptop boot.  Up until I did a yum update today, enforce mode was working perfectly.


Version-Release number of selected component (if applicable):

libselinux-utils-2.0.99-4.fc15.x86_64
libselinux-devel-2.0.99-4.fc15.x86_64
libselinux-python-2.0.99-4.fc15.x86_64
selinux-policy-3.9.16-35.fc15.noarch
selinux-policy-targeted-3.9.16-35.fc15.noarch
libselinux-2.0.99-4.fc15.x86_64

How reproducible:

???

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Miroslav Grepl 2011-08-05 06:58:02 UTC
Could you add outputs of

# dmesg |grep avc

# ausearch -m avc -ts recent

# systemctl status auditd.service


after booting in permissive mode.

Comment 2 Bill C. Riemers 2011-08-05 12:41:20 UTC
Here is the requested information.  The first command is reporting denials which probably are related.  The next two seem to be reporting a dnsmasq problem that has existed for awhile, and I already reported as a separate bug.

I forgot to mention one of the other deamons that could not complete start-up in enforce mode was autofs.  Another thing I should mention is one of the many things I tried was a fresh install.  However, after a yum update the new install base had the same problem as the old one.

[root@docbillthink sbin]# dmesg |grep avc
[   21.121765] type=1400 audit(1312510879.973:3): avc:  denied  { mmap_zero } for  pid=607 comm="vbetool" scontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tcontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tclass=memprotect
[   26.220844] type=1400 audit(1312510885.071:4): avc:  denied  { mac_admin } for  pid=1 comm="systemd" capability=33  scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=capability2
[   30.462827] dbus[1088]: avc:  netlink poll: error 4
[root@docbillthink sbin]# ausearch -m avc -ts recent
----
time->Fri Aug  5 08:31:27 2011
type=SYSCALL msg=audit(1312547487.332:83): arch=c000003e syscall=16 success=no exit=-19 a0=9 a1=8915 a2=7fffee423e90 a3=0 items=0 ppid=1 pid=1348 auid=4294967295 uid=99 gid=40 euid=99 suid=99 fsuid=99 egid=40 sgid=40 fsgid=40 tty=(none) ses=4294967295 comm="dnsmasq" exe="/usr/sbin/dnsmasq" subj=system_u:system_r:dnsmasq_t:s0 key=(null)
type=AVC msg=audit(1312547487.332:83): avc:  denied  { module_request } for  pid=1348 comm="dnsmasq" kmod="netdev-tun0,tap0" scontext=system_u:system_r:dnsmasq_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=system
[root@docbillthink sbin]# systemctl status auditd.service
auditd.service - SYSV: This starts the Linux Auditing System Daemon, which collects security related events in a dedicated audit log. If this daemon is turned off, audit events will be sent to syslog.
	  Loaded: loaded (/etc/rc.d/init.d/auditd)
	  Active: active (running) since Thu, 04 Aug 2011 22:21:35 -0400; 10h ago
	 Process: 1155 ExecStart=/etc/rc.d/init.d/auditd start (code=exited, status=0/SUCCESS)
	Main PID: 1167 (auditd)
	  CGroup: name=systemd:/system/auditd.service
		  ├ 1167 auditd
		  ├ 1169 /sbin/audispd
		  └ 1171 /usr/sbin/sedispatch

Comment 3 Daniel Walsh 2011-08-05 14:21:48 UTC
Remove vbetool, most likely you do not need this.

The mac_admin one is curious and we probably want to talk to Lennart about this one.

mac_admin means that systemd is trying to place a label on the system that the kernel does not understand.

I believe a fix for dnsmasq is in the works.

Comment 4 Bill C. Riemers 2011-08-05 14:36:21 UTC
The vbetool failure is probably why my laptop display ends up very dim in console mode...

Comment 5 Daniel Walsh 2011-08-05 14:51:18 UTC
I have been told that vbetool is not needed for most hardware,  you could test this theory out by makeing vbetool permissive and seeing if this fixes you console problem.

semanage permissive -a vbetool_t