I just finished debugging an issue with kdump startup. (systemd was unable to load the kdump kernel, even though using the kdumpctl command from a shell worked just fine.) These symptoms immediately made me think that the problem might be SELinux-related, and my /boot directory was indeed not labeled correctly.
It took me quite a bit longer than it should have to figure out what was going on, however, because no denials were reported -- either in the audit log or by ausearch. It was only when I put SELinux in permissive mode "just to doublecheck" that anything was reported:
time->Sun Nov 18 22:42:13 2012 type=SYSCALL msg=audit(1353300133.076:93): arch=c000003e syscall=5 success=yes exit=0 a0=3 a1=7fff0a12e0e0 a2=7fff0a12e0e0 a3=7fff0a12de70 items=0 ppid=3402 pid=3422 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="kexec" exe="/usr/sbin/kexec" subj=system_u:system_r:kdump_t:s0 key=(null) type=AVC msg=audit(1353300133.076:93): avc: denied { getattr } for pid=3422 comm="kexec" path="/boot/initramfs-3.6.6-1.fc17.x86_64kdump.img" dev="md0" ino=19 scontext=system_u:system_r:kdump_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file ---- time->Sun Nov 18 22:42:13 2012 type=SYSCALL msg=audit(1353300133.076:92): arch=c000003e syscall=2 success=yes exit=3 a0=7fff0a12fee4 a1=0 a2=a a3=7fff0a12de70 items=0 ppid=3402 pid=3422 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="kexec" exe="/usr/sbin/kexec" subj=system_u:system_r:kdump_t:s0 key=(null) type=AVC msg=audit(1353300133.076:92): avc: denied { open } for pid=3422 comm="kexec" path="/boot/initramfs-3.6.6-1.fc17.x86_64kdump.img" dev="md0" ino=19 scontext=system_u:system_r:kdump_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file type=AVC msg=audit(1353300133.076:92): avc: denied { read } for pid=3422 comm="kexec" name="initramfs-3.6.6-1.fc17.x86_64kdump.img" dev="md0" ino=19 scontext=system_u:system_r:kdump_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file
Is this expected behavior for some reason? Anyone ever seen anything like this?
On Sun, Nov 18, 2012 at 22:58:14 -0600, Ian Pilcher arequipeno@gmail.com wrote:
Is this expected behavior for some reason? Anyone ever seen anything like this?
There are don't audit rules. You disable don't audit rules using semodule -DB . semodule -B will restore things to the normal state.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/18/2012 11:58 PM, Ian Pilcher wrote:
I just finished debugging an issue with kdump startup. (systemd was unable to load the kdump kernel, even though using the kdumpctl command from a shell worked just fine.) These symptoms immediately made me think that the problem might be SELinux-related, and my /boot directory was indeed not labeled correctly.
It took me quite a bit longer than it should have to figure out what was going on, however, because no denials were reported -- either in the audit log or by ausearch. It was only when I put SELinux in permissive mode "just to doublecheck" that anything was reported:
time->Sun Nov 18 22:42:13 2012 type=SYSCALL msg=audit(1353300133.076:93): arch=c000003e syscall=5 success=yes exit=0 a0=3 a1=7fff0a12e0e0 a2=7fff0a12e0e0 a3=7fff0a12de70 items=0 ppid=3402 pid=3422 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="kexec" exe="/usr/sbin/kexec" subj=system_u:system_r:kdump_t:s0 key=(null) type=AVC msg=audit(1353300133.076:93): avc: denied { getattr } for pid=3422 comm="kexec" path="/boot/initramfs-3.6.6-1.fc17.x86_64kdump.img" dev="md0" ino=19 scontext=system_u:system_r:kdump_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file ---- time->Sun Nov 18 22:42:13 2012 type=SYSCALL msg=audit(1353300133.076:92): arch=c000003e syscall=2 success=yes exit=3 a0=7fff0a12fee4 a1=0 a2=a a3=7fff0a12de70 items=0 ppid=3402 pid=3422 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="kexec" exe="/usr/sbin/kexec" subj=system_u:system_r:kdump_t:s0 key=(null) type=AVC msg=audit(1353300133.076:92): avc: denied { open } for pid=3422 comm="kexec" path="/boot/initramfs-3.6.6-1.fc17.x86_64kdump.img" dev="md0" ino=19 scontext=system_u:system_r:kdump_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file type=AVC msg=audit(1353300133.076:92): avc: denied { read } for pid=3422 comm="kexec" name="initramfs-3.6.6-1.fc17.x86_64kdump.img" dev="md0" ino=19 scontext=system_u:system_r:kdump_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file
Is this expected behavior for some reason? Anyone ever seen anything like this?
Looks like you hit a problem with a dontaudit rules. If you still have the problem setup and did a
semodule -DB
I would turn of the dontaudit rule which might have been blocking you from seeing the AVC. sesearch --dontaudit -s kdump_t -t file_t Found 1 semantic av rules: dontaudit application_domain_type file_type : dir { getattr search open } ;
Seems to have blocked you from seeing the AVC. Before systemd, we needed this since every time an admin would restart a service in a random directory the cwd would be checked and generate AVC's. Since we now have systemd, we can remove this dontaudit. I do this in Rawhide and see if there is an upswing in AVC messages.
selinux@lists.fedoraproject.org
-
Bruno Wolff III -
Daniel J Walsh -
Ian Pilcher