Hide Forgot
Description of problem: iprinit, iprdump and iprupdate services work well with targeted policy, but they struggle with MLS policy. iprinit - IBM Power RAID adapter/device initialization utility iprupdate - IBM Power RAID adapter/device microcode update utility iprdump - IBM Power RAID adapter dump utility Version-Release number of selected component (if applicable): selinux-policy-mls-3.7.19-63.el6.noarch selinux-policy-3.7.19-63.el6.noarch selinux-policy-minimum-3.7.19-63.el6.noarch selinux-policy-targeted-3.7.19-63.el6.noarch selinux-policy-doc-3.7.19-63.el6.noarch iprutils-2.2.20-1.el6.ppc64 How reproducible: always Steps to Reproduce: (have a ppc64 machine with MLS policy installed, runlevel 3, logged in as root via console) # run_init service iprinit restart # run_init service iprupdate restart # run_init service iprdump restart # ausearch -m avc -ts recent Actual results: ---- time->Thu Jan 13 10:17:25 2011 type=SYSCALL msg=audit(1294931845.566:353): arch=80000015 syscall=5 success=no e xit=-13 a0=10039791192 a1=2 a2=0 a3=8 items=0 ppid=1 pid=1620 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="iprinit" exe ="/usr/sbin/iprinit" subj=system_u:system_r:initrc_t:s0-s15:c0.c1023 key=(null) type=AVC msg=audit(1294931845.566:353): avc: denied { read write } for pid=16 20 comm="iprinit" name="sg0" dev=devtmpfs ino=6942 scontext=system_u:system_r:in itrc_t:s0-s15:c0.c1023 tcontext=system_u:object_r:scsi_generic_device_t:s0 tclas s=chr_file ---- time->Thu Jan 13 10:19:32 2011 type=SYSCALL msg=audit(1294931972.152:462): arch=80000015 syscall=102 success=no exit=-13 a0=1 a1=fffd1debd30 a2=f a3=e7 items=0 ppid=1 pid=1681 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="iprdump" exe="/usr/sbin/iprdump" subj=system_u:system_r:initrc_t:s0-s15:c0.c1023 key=(null) type=AVC msg=audit(1294931972.152:462): avc: denied { create } for pid=1681 comm="iprdump" scontext=system_u:system_r:initrc_t:s0-s15:c0.c1023 tcontext=system_u:system_r:initrc_t:s0-s15:c0.c1023 tclass=netlink_kobject_uevent_socket ---- Expected results: no denials
Milos, could you try to treat these service with the raid policy. # run_init service $services stop # chcon -t mdadm_exec_t PATH_TO_EXECUTABLES # run_init service $services start
Testing with different context: # rpm -ql iprutils | grep usr/sbin | xargs ls -Z -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /usr/sbin/iprconfig -rwx------. root root system_u:object_r:bin_t:s0 /usr/sbin/iprdbg -rwxr-xr-x. root root system_u:object_r:mdadm_exec_t:s0 /usr/sbin/iprdump -rwxr-xr-x. root root system_u:object_r:mdadm_exec_t:s0 /usr/sbin/iprinit -rwxr-xr-x. root root system_u:object_r:mdadm_exec_t:s0 /usr/sbin/iprupdate All 3 services are able to start, but following AVCs appeared many times: ---- time->Fri Jan 14 05:57:02 2011 type=SYSCALL msg=audit(1295002622.864:345): arch=80000015 syscall=5 success=no exit=-13 a0=10034f50432 a1=2 a2=0 a3=8 items=0 ppid=1716 pid=1717 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1 comm="iprinit" exe="/usr/sbin/iprinit" subj=system_u:system_r:mdadm_t:s0-s15:c0.c1023 key=(null) type=AVC msg=audit(1295002622.864:345): avc: denied { write } for pid=1717 comm="iprinit" name="sg0" dev=devtmpfs ino=7026 scontext=system_u:system_r:mdadm_t_t:s0-s15:c0.c1023 tcontext=system_u:object_r:scsi_generic_device_t:s0 tclass=chr_file ---- time->Fri Jan 14 06:00:12 2011 type=SYSCALL msg=audit(1295002812.444:429): arch=80000015 syscall=102 success=no exit=-13 a0=1 a1=fffe8e53010 a2=f a3=e7 items=0 ppid=1 pid=1764 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="iprdump" exe="/usr/sbin/iprdump" subj=system_u:system_r:mdadm_t:s0-s15:c0.c1023 key=(null) type=AVC msg=audit(1295002812.444:429): avc: denied { create } for pid=1764 comm="iprdump" scontext=system_u:system_r:mdadm_t:s0-s15:c0.c1023 tcontext=system_u:system_r:mdadm_t:s0-s15:c0.c1023 tclass=netlink_kobject_uevent_socket ----
Could test it in permissive mode and collect AVC messages. Looks like we could treat these services with the raid policy. Also could you look for pid, log files for these services?
I see 2 additional AVCs in permissive mode: ---- time->Tue Jan 18 10:15:04 2011 type=SYSCALL msg=audit(1295363704.098:11): arch=80000015 syscall=102 success=yes exit=0 a0=2 a1=fffd08ff4d0 a2=c a3=0 items=0 ppid=1 pid=1306 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iprinit" exe="/usr/sbin/iprinit" subj=system_u:system_r:mdadm_t:s0-s15-s15:c0.c1023 key=(null) type=AVC msg=audit(1295363704.098:11): avc: denied { bind } for pid=1306 comm="iprinit" scontext=system_u:system_r:mdadm_t:s0-s15:c0.c1023 tcontext=system_m_u:system_r:mdadm_t:s0-s15:c0.c1023 tclass=netlink_kobject_uevent_socket ---- time->Tue Jan 18 10:15:04 2011 type=SYSCALL msg=audit(1295363704.098:12): arch=80000015 syscall=102 success=no exit=-11 a0=a a1=fffd08ff4d0 a2=400 a3=0 items=0 ppid=1 pid=1306 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iprinit" exe="/usr/sbin/iprinit" subj=system_u:system_r:mdadm_t:s0-:s0-s15:c0.c1023 key=(null) type=AVC msg=audit(1295363704.098:12): avc: denied { read } for pid=1306 comm="iprinit" scontext=system_u:system_r:mdadm_t:s0-s15:c0.c1023 tcontext=system_m_u:system_r:mdadm_t:s0-s15:c0.c1023 tclass=netlink_kobject_uevent_socket ----
Following 2 AVCs are not directly related to iprutils package, but they appeared when I used "run_init service ipr... restart": ---- time->Tue Jan 18 10:17:15 2011 type=SYSCALL msg=audit(1295363835.930:35): arch=80000015 syscall=102 success=yes exit=0 a0=3 a1=ffffd988ab0 a2=21 a3=6c items=0 ppid=1566 pid=1596 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=hvc0 ses=1 comm="run_ini it" exe="/usr/sbin/run_init" subj=root:sysadm_r:run_init_t:s0-s15:c0.c1023.c1023 key=(null) type=AVC msg=audit(1295363835.930:35): avc: denied { connectto } for pid=1596 comm="run_init" path="/var/run/dbus/system_bus_socket" scontext=root:sysadm_r_r:run_init_t:s0-s15:c0.c1023 tcontext=system_u:system_r:system_dbusd_t:s0-s1515:c0.c1023 tclass=unix_stream_socket type=AVC msg=audit(1295363835.930:35): avc: denied { write } for pid=1596 comm="run_init" name="system_bus_socket" dev=dm-0 ino=3146234 scontext=root:sysadadm_r:run_init_t:s0-s15:c0.c1023 tcontext=system_u:object_r:system_dbusd_var_r_run_t:s0 tclass=sock_file ----
Is there some pam module that run_init is using that is talking to dbus?
# strace -o vystup.txt run_init service iprinit status # grep -C 1 dbus vystup.txt close(5) = 0 open("/usr/lib64/libdbus-glib-1.so.2", O_RDONLY) = 5 read(5, "\177ELF\2\2\1\0\0\0\0\0\0\0\0\0\0\3\0\25\0\0\0\1\0\0\0\0\0\3\23\360"..., 832) = 832 -- close(5) = 0 open("/lib64/libdbus-1.so.3", O_RDONLY) = 5 read(5, "\177ELF\2\2\1\0\0\0\0\0\0\0\0\0\0\3\0\25\0\0\0\1\0\0\0\0\0\10\34X"..., 832) = 832 -- socket(PF_FILE, SOCK_STREAM, 0) = 3 connect(3, {sa_family=AF_FILE, path="/var/run/dbus/system_bus_socket"}, 33) = 0 fcntl(3, F_GETFL) = 0x2 (flags O_RDWR) -- socket(PF_FILE, SOCK_STREAM, 0) = 4 connect(4, {sa_family=AF_FILE, path="/var/run/dbus/system_bus_socket"}, 33) = 0 fcntl(4, F_GETFL) = 0x2 (flags O_RDWR) #
I guess so. Miroslav add the policy to allow run_init and newrole to talk to dbus.
Fixed in selinux-policy-3.7.19-67.el6
Seen today on machine with active MLS policy during the boot up sequence: type=1400 audit(1299783230.921:3): avc: denied { write } for pid=1296 comm="iprinit" name="queue_depth" dev=sysfs ino=6225 scontext=system_u:system_r:mdadm_t:s0-s15:c0.c1023 tcontext=system_u:object_r:sysfs_t:s0 tclass=file # rpm -qa | grep -e selinux-policy -e iprutils | sort iprutils-2.3.2-1.el6.ppc64 selinux-policy-3.7.19-78.el6.noarch selinux-policy-doc-3.7.19-78.el6.noarch selinux-policy-minimum-3.7.19-78.el6.noarch selinux-policy-mls-3.7.19-78.el6.noarch selinux-policy-targeted-3.7.19-78.el6.noarch
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0526.html