Bug 530972 - AVC denial messages on multipathd tests
AVC denial messages on multipathd tests
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: selinux-policy (Show other bugs)
5.3
All Linux
low Severity medium
: rc
: ---
Assigned To: Daniel Walsh
BaseOS QE Security Team
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-10-26 06:44 EDT by michal novacek
Modified: 2009-11-10 10:17 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-10 10:17:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
log from rhts avc denials (101 bytes, text/plain)
2009-10-26 06:44 EDT, michal novacek
no flags Details

  None (edit)
Description michal novacek 2009-10-26 06:44:14 EDT
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
----
Comment 1 Daniel Walsh 2009-10-26 08:44:46 EDT
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.
Comment 2 michal novacek 2009-10-27 06:25:46 EDT
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?
Comment 3 Daniel Walsh 2009-10-27 09:48:34 EDT
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.
Comment 4 michal novacek 2009-10-30 06:12:13 EDT
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?
Comment 5 Daniel Walsh 2009-10-30 08:16:00 EDT
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.
Comment 6 michal novacek 2009-11-02 03:58:29 EST
These devices are created by multipath udev rules. I blame them for bad context labeling of new devices then, right?
Comment 7 Daniel Walsh 2009-11-02 10:08:57 EST
Yes either them or udev.

Note You need to log in before you can comment on or make changes to this bug.