Created attachment 366088 [details] log from rhts avc denials Description of problem: On running tests in rhts with iscsid/multipathd I have a lot of avc denial messages from "pam_console_apply" Version-Release number of selected component (if applicable): RHEL5-Server-U4 selinux-policy-2.4.6-255.el5_4.1.noarch How reproducible: always Steps to Reproduce: 1. run /kernel/storage/device-mapper/multipath rhts test Actual results: AVC denial messages Expected results: clear blue sky Additional info: all denial messages looks like this: time->Fri Oct 23 15:02:52 2009 type=SYSCALL msg=audit(1256324572.395:12): arch=40000003 syscall=5 success=no exit=-13 a0=bfe664b0 a1=18800 a2=3f4ff4 a3=0 items=0 ppid=11767 pid=11776 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="pam_console_app" exe="/sbin/pam_console_apply" subj=system_u:system_r:pam_console_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1256324572.395:12): avc: denied { read } for pid=11776 comm="pam_console_app" name="/" dev=dm-4 ino=2 scontext=system_u:system_r:pam_console_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=dir ----
You could not have any files labeled file_t on your system. This indicates a file without a label. So either you have a badly mislabelled system or you added a disk without labels. You can relabel the system using fixfiles restore or touch /.autorelabel; reboot If you just added a new disk, you can run restorecon on the new disk.
That is not what happened -- in my opinion there are files created by device-mapper that do not have correct labels, as you say. As these files are created during common usage of multipathd I do still see it as a bug. Can you confirm that this is right or wrong?
I guess if multipath creates a new volume and mounts it. It will have no labels on it and be labeled file_t which pam_console will then try to read? It could happen. If you want to eliminate this avc, you will need to change the test to run a restorecon on the newly created disks.
In other words, when there are new devices created on usual locations (/dev /dev/mapper /dev/mpath) it is correct that there are no labels created on these newly created devices and the only way to go is to "restorocon" after creating them?
The default for any file/device created anywhere in an SELinux system is to adopt the parent directories label. (device_t) in this case. The only way to change this behaviour is to either use an SELinux aware application like udev/restorecon or make your app SELinux aware, or to write a transition rule in policy. SELinux policy can be written to say if a process labeled A creates a FILE in a directory labeled B, it will create it labeled C. But we can only write one of these so if the same process wants to create a FILE labeled D in the same directory, then it needs to be SELinux aware. Best solution is to get udev to create all devices for you, secondarily would be for you app to grow selinux awareness by either asking SELinux how to label a file before you create it and then telling the kernel to create the next device with this label. Or create the device and run restorecon to fix its context.
These devices are created by multipath udev rules. I blame them for bad context labeling of new devices then, right?
Yes either them or udev.