Hide Forgot
Description of problem: selinux-policy-3.9.16-5.fc16.noarch is generated sys_module AVCs: #============= udev_t ============== allow udev_t self:capability sys_module; #============= virtd_t ============== allow virtd_t self:capability sys_module; The first of these occurs quite early during boot ('dmesg | grep avc'): [ 12.115883] type=1400 audit(1300453581.521:3): avc: denied { sys_module } for pid=778 comm="iw" capability=16 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 tcontext=system_u:system_r:udev_t:s0-s0:c0.c1023 tclass=capability The second one has more audit info: type=SERVICE_START msg=audit(1300453594.022:31): user pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=': comm="libvirtd" exe="/bin/systemd" hostname=? addr=? terminal=? res=success' type=AVC msg=audit(1300453594.123:32): avc: denied { sys_module } for pid=1331 comm="libvirtd" capability=16 scontext=system_u:system_r:virtd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:virtd_t:s0-s0:c0.c1023 tclass=capability type=SYSCALL msg=audit(1300453594.123:32): arch=c000003e syscall=16 success=no exit=-19 a0=4 a1=8913 a2=7fffcd550270 a3=7fffcd54ff90 items=0 ppid=1 pid=1331 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="libvirtd" exe="/usr/sbin/libvirtd" subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 key=(null) Version-Release number of selected component (if applicable): selinux-policy-3.9.16-5.fc16.noarch How reproducible: Every boot Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Forgot to include: Running kernel-2.6.38-1.fc15.x86_64
Eric do you think this is a similar problem that we saw with network manager?
The udev one, yes, looks like it. Not sure if it's a kernel or a udev bug. The libvirt one, it's hard to tell, but possible.....
Is there any chance you can reproduce this problem with selinux permissive and then provide the output of dmesg?
Created attachment 486720 [details] dmesg output from permissive boot with sys_module AVCs Sure. No problem. But the dmesg output doesn't show the virtd_t sys_module AVC. Here is a bit of context for that: Mar 21 06:11:49 tlondon gdm-simple-slave[1431]: DEBUG(+): GdmWelcomeSession: welcome environment: USER=gdm Mar 21 06:11:49 tlondon gdm-simple-slave[1431]: DEBUG(+): GdmWelcomeSession: welcome environment: SHELL=/sbin/nologin Mar 21 06:11:49 tlondon gdm-simple-slave[1431]: DEBUG(+): GdmWelcomeSession: welcome environment: PATH=/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/sbin:/sbin:/usr/sbin:/bin:/usr/bin Mar 21 06:11:49 tlondon gdm-simple-slave[1530]: DEBUG(+): GdmWelcomeSession: Setting up run time dir /var/run/gdm/greeter Mar 21 06:11:49 tlondon gdm-simple-slave[1530]: DEBUG(+): GdmWelcomeSession: Changing (uid:gid) for child process to (42:476) Mar 21 06:11:49 tlondon setroubleshoot: SELinux is preventing /sbin/rsyslogd from using the sys_nice capability. For complete SELinux messages. run sealert -l 2d7d0598-83cc-4efc-a56d-2f0b98e1b67d Mar 21 06:11:49 tlondon setroubleshoot: SELinux is preventing /sbin/rsyslogd from using the sys_nice capability. For complete SELinux messages. run sealert -l 2d7d0598-83cc-4efc-a56d-2f0b98e1b67d Mar 21 06:11:49 tlondon setroubleshoot: SELinux is preventing /usr/sbin/libvirtd from using the sys_module capability. For complete SELinux messages. run sealert -l 5763ea36-65ae-43fb-8b21-a36465293bf7 Mar 21 06:11:49 tlondon gdm-simple-slave[1431]: DEBUG(+): GdmWelcomeSession: Started D-Bus daemon on pid 1536 Mar 21 06:11:49 tlondon gdm-simple-slave[1431]: DEBUG(+): GdmWelcomeSession: welcome environment: DISPLAY=:0 Mar 21 06:11:49 tlondon gdm-simple-slave[1431]: DEBUG(+): GdmWelcomeSession: welcome environment: DCONF_PROFILE=gdm Mar 21 06:11:49 tlondon gdm-simple-slave[1431]: DEBUG(+): GdmWelcomeSession: welcome environment: HOME=/var/lib/gdm Mar 21 06:11:49 tlondon gdm-simple-slave[1431]: DEBUG(+): GdmWelcomeSession: welcome environment: GDM_SEAT_ID=Seat1
In case anyone was interested, my current thought is that this is because of http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8909c9ad8ff03611c9c96c9a92656213e4bb495b but that should have come with a dmesg error in permissive I'm trying to run down exactly what is going wrong....
Created attachment 486807 [details] Always print message on fallback Latest thought, because I'm not able to reproduce. I think this could happen if you try to autoload a module that doesn't exist. We will get this AVC and we will not get the printk... Anyone in a position to test in permissive with this patch and then include dmesg?
I'm attempting a local build of kernel-2.6.38-5.fc15 with this patch. I should be able to test this tonight.
Created attachment 487176 [details] output of 'dmesg' after booting permissively with patched kernel I did a local build including the patch. here is diff of spec file: 26c26 < %define buildid .local --- > # % define buildid .local 737d736 < Patch13000: always-print-on-fallback.patch 1369d1367 < ApplyPatch always-print-on-fallback.patch [tbl@tlondon SPECS]$ diff -u kernel* --- kernel.spec 2011-03-23 07:04:46.181236586 -0700 +++ kernel.spec.old 2011-03-22 19:08:34.662713684 -0700 @@ -23,7 +23,7 @@ # # (Uncomment the '#' and both spaces below to set the buildid.) # -%define buildid .local +# % define buildid .local ################################################################### # The buildid can also be specified on the rpmbuild command line @@ -734,7 +734,6 @@ Patch12421: fs-call-security_d_instantiate-in-d_obtain_alias.patch -Patch13000: always-print-on-fallback.patch %endif BuildRoot: %{_tmppath}/kernel-%{KVERREL}-root @@ -1366,7 +1365,6 @@ # rhbz#662344,600690 ApplyPatch fs-call-security_d_instantiate-in-d_obtain_alias.patch -ApplyPatch always-print-on-fallback.patch # END OF PATCH APPLICATIONS %endif I installed and rebooted permissively: [root@tlondon ~]# uname -a Linux tlondon.localhost.org 2.6.38-5.local.fc16.x86_64 #1 SMP Wed Mar 23 08:00:15 PDT 2011 x86_64 x86_64 x86_64 GNU/Linux [root@tlondon ~]# [root@tlondon ~]# getenforce Permissive [root@tlondon ~]# I attach output of dmesg.
*** This bug has been marked as a duplicate of bug 684415 ***