| Summary: | Can't start virtual machine when selinux is in enforce mode | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Arnold Wang <arnold.x.wang> |
| Component: | selinux-policy-targeted | Assignee: | Miroslav Grepl <mgrepl> |
| Status: | CLOSED NOTABUG | QA Contact: | Ben Levenson <benl> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 16 | CC: | dwalsh |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-03-06 09:34:53 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
audit2allow -i /tmp/t #============= svirt_t ============== #!!!! This avc can be allowed using the boolean 'virt_use_execmem' allow svirt_t self:process execmem; You did not include the var_log_t avc. But I think this is probably a mislabeled file. I just tried the following:
1. touch /.autorelabel; reboot
2. setsebool -P virt_use_execmem=true
and as far as I can tell, no difference made.
-bash-4.2# getsebool virt_use_execmem
virt_use_execmem --> on
-bash-4.2# audit2allow -alr
require {
type iscsid_t;
type var_log_t;
type svirt_t;
class process execmem;
class file open;
}
#============= iscsid_t ==============
allow iscsid_t var_log_t:file open;
#============= svirt_t ==============
allow svirt_t self:process execmem;
#============= svirt_t ============== allow svirt_t self:process execmem; is allowed in the latest F17 policy. You will need to update. #============= iscsid_t ============== allow iscsid_t var_log_t:file open; What does $ ls -Z /var/log/iscs* [awang@mars ~]$ ls -lZ /var/log/iscs* -rw-r--r--. root root system_u:object_r:var_log_t:s0 /var/log/iscsiuio.log -rw-r--r--. root root system_u:object_r:var_log_t:s0 /var/log/iscsiuio.log-20120212 -rw-r--r--. root root system_u:object_r:var_log_t:s0 /var/log/iscsiuio.log-20120221 $ restorecon -R -v /var/log/iscsiui* Did you start iscsid by hand? I mean without using either service script or systemd unit file? No, I didn't start the iscsi manually. Besides, as you can see from my comments before, I have relabeled the file systems many times and didn't make any difference. Any way, I just did again. --- before --- -bash-4.2# ls -lZ /var/log/iscsiui* -rw-r--r--. root root system_u:object_r:var_log_t:s0 /var/log/iscsiuio.log -rw-r--r--. root root system_u:object_r:var_log_t:s0 /var/log/iscsiuio.log-20120212 -rw-r--r--. root root system_u:object_r:var_log_t:s0 /var/log/iscsiuio.log-20120221 -rw-r--r--. root root system_u:object_r:var_log_t:s0 /var/log/iscsiuio.log-20120302 -rw-r--r--. root root system_u:object_r:var_log_t:s0 /var/log/iscsiuio.log-20120305 --- relabel them --- -bash-4.2# restorecon -R -v /var/log/iscsiui* --- looks exactly as what they were --- -bash-4.2# ls -lZ /var/log/iscsiui* -rw-r--r--. root root system_u:object_r:var_log_t:s0 /var/log/iscsiuio.log -rw-r--r--. root root system_u:object_r:var_log_t:s0 /var/log/iscsiuio.log-20120212 -rw-r--r--. root root system_u:object_r:var_log_t:s0 /var/log/iscsiuio.log-20120221 -rw-r--r--. root root system_u:object_r:var_log_t:s0 /var/log/iscsiuio.log-20120302 -rw-r--r--. root root system_u:object_r:var_log_t:s0 /var/log/iscsiuio.log-20120305 -bash-4.2# Since nothing changed in the labels, not sure how that can fix my problem. If iscsi logs files need special label, they're NOT defined in the policy shipped. -bash-4.2# grep -i iscsi /etc/selinux/targeted/contexts/files/file_contexts* /etc/selinux/targeted/contexts/files/file_contexts:/var/lib/iscsi(/.*)? system_u:object_r:iscsi_var_lib_t:s0 /etc/selinux/targeted/contexts/files/file_contexts:/var/lock/iscsi(/.*)? system_u:object_r:iscsi_lock_t:s0 /etc/selinux/targeted/contexts/files/file_contexts:/sbin/iscsid -- system_u:object_r:iscsid_exec_t:s0 /etc/selinux/targeted/contexts/files/file_contexts:/sbin/iscsiuio -- system_u:object_r:iscsid_exec_t:s0 /etc/selinux/targeted/contexts/files/file_contexts:/sbin/brcm_iscsiuio -- system_u:object_r:iscsid_exec_t:s0 /etc/selinux/targeted/contexts/files/file_contexts:/var/run/iscsid\.pid -- system_u:object_r:iscsi_var_run_t:s0 /etc/selinux/targeted/contexts/files/file_contexts:/var/log/brcm-iscsi\.log -- system_u:object_r:iscsi_log_t:s0 The defined one is for /var/log/brcm-iscsi\.log. I'm disappointed you closed this without even waiting for the result from the user. With a response like this, I don't know how you expect people will continue file bug report in the future. Thanks. I see the label in selinux-policy-3.10.0-77.fc16 1. What's the label should be? I can verify the fix manually if you tell me what's the "correct" label should be? I tried "system_u:object_r:iscsi_log_t:s0" for /var/log/iscsi* and it didn't help. 2. The latest "published" selinux-policy seems to me is still 3.10.0-75. I can wait for it be realised to try again. Thanks. *** Bug 798746 has been marked as a duplicate of this bug. *** Yes that is the label, what do you mean it does not work? Here is what I just tried. Please let me know if I did anything wrong.
-bash-4.2# chcon system_u:object_r:iscsi_log_t:s0 /var/log/iscsiuio.log*
-bash-4.2# ls -lZ /var/log/iscsiuio.log*
-rw-r--r--. root root system_u:object_r:iscsi_log_t:s0 /var/log/iscsiuio.log
-rw-r--r--. root root system_u:object_r:iscsi_log_t:s0 /var/log/iscsiuio.log-20120212
-rw-r--r--. root root system_u:object_r:iscsi_log_t:s0 /var/log/iscsiuio.log-20120221
-rw-r--r--. root root system_u:object_r:iscsi_log_t:s0 /var/log/iscsiuio.log-20120302
-rw-r--r--. root root system_u:object_r:iscsi_log_t:s0 /var/log/iscsiuio.log-20120305
After that, I launched the guest machine and received the following alert:
SELinux is preventing /sbin/iscsiuio from open access on the file /var/log/iscsiuio.log.
***** Plugin catchall (100. confidence) suggests ***************************
If you believe that iscsiuio should be allowed open access on the iscsiuio.log file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep iscsiuio /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
Additional Information:
Source Context system_u:system_r:iscsid_t:s0
Target Context system_u:object_r:var_log_t:s0
Target Objects /var/log/iscsiuio.log [ file ]
Source iscsiuio
Source Path /sbin/iscsiuio
Port <Unknown>
Host mars.astro.net
Source RPM Packages iscsi-initiator-utils-6.2.0.872-16.fc16.x86_64
Target RPM Packages
Policy RPM selinux-policy-3.10.0-75.fc16.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Permissive
Host Name mars.astro.net
Platform Linux mars.astro.net 3.2.9-1.fc16.x86_64 #1 SMP
Thu Mar 1 01:41:10 UTC 2012 x86_64 x86_64
Alert Count 1
First Seen Wed 07 Mar 2012 03:45:29 PM PST
Last Seen Wed 07 Mar 2012 03:45:29 PM PST
Local ID 2acb1cb2-1cfe-4157-a691-ff7d038d0c50
Raw Audit Messages
type=AVC msg=audit(1331163929.416:59): avc: denied { open } for pid=1264 comm="iscsiuio" name="iscsiuio.log" dev=dm-6 ino=4308 scontext=system_u:system_r:iscsid_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file
type=SYSCALL msg=audit(1331163929.416:59): arch=x86_64 syscall=open success=yes exit=ESRCH a0=4203b0 a1=441 a2=1b6 a3=238 items=0 ppid=1263 pid=1264 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=iscsiuio exe=/sbin/iscsiuio subj=system_u:system_r:iscsid_t:s0 key=(null)
Hash: iscsiuio,iscsid_t,var_log_t,file,open
audit2allow
#============= iscsid_t ==============
allow iscsid_t var_log_t:file open;
audit2allow -R
#============= iscsid_t ==============
allow iscsid_t var_log_t:file open;
Ok, I rebooted the machine and that "fixed" the problem. I always assumed these labels can be changed on the fly. Regarding the other earlier comment on 'virt_use_execmem', I want to make sure I understand its status correctly. Miroslav mentioned that 'virt_use_execmem' is only available in the latest F17 policy, howeve when I did 'getsebool -a', I found it. Of course, when I tried to enable it, it didn't make any difference. -bash-4.2# getsebool virt_use_execmem virt_use_execmem --> on Can someone explain it in more detail of this? If I'm going to stay with F16, do I have to build my own customized module so I can set the SELinux to enforce mode again? Thanks. 'virt_use_execmem' is also in F16 but it had a different meaning which I fixed and now F16==F17 related to this boolean. How do you start iscsid service? Thanks for the explanation. It makes senses now. 1. I'm curious when I can expect to "receive" your fix via "yum update". 2. The iscsid service is started by the system. Since this is my home PC and I don't have iscsi devices around at all, there is no need for me to mess around the iscsid service at all. -bash-4.2# systemctl is-enabled iscsid.service iscsid.service is not a native service, redirecting to /sbin/chkconfig. Executing /sbin/chkconfig iscsid --level=5 enabled -bash-4.2# |
Description of problem: When the selinux is in enforce mode, I can't start the guest machine. I manually relabel the file system and it didn't help. "audit2allow -alr" generates the following: -bash-4.2# audit2allow -alr require { type iscsid_t; type var_log_t; type svirt_t; class process execmem; class file open; } #============= iscsid_t ============== allow iscsid_t var_log_t:file open; #============= svirt_t ============== allow svirt_t self:process execmem; The raw audit logs: type=VIRT_MACHINE_ID msg=audit(1330541247.189:187): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 vm-ctx=system_u:system_r:svirt_t:s0:c759,c959 img-ctx=system_u:object_r:svirt_image_t:s0:c759,c959: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success' type=VIRT_RESOURCE msg=audit(1330541247.225:188): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=cgroup reason=deny vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 cgroup="/sys/fs/cgroup/devices/libvirt/qemu/Windows7/" class=all: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success' type=VIRT_RESOURCE msg=audit(1330541247.225:189): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=cgroup reason=allow vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 cgroup="/sys/fs/cgroup/devices/libvirt/qemu/Windows7/" class=major category=pty maj=88 acl=rw: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success' type=VIRT_RESOURCE msg=audit(1330541247.225:190): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=cgroup reason=allow vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 cgroup="/sys/fs/cgroup/devices/libvirt/qemu/Windows7/" class=path path=/dev/null rdev=01:03 acl=rw: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success' type=VIRT_RESOURCE msg=audit(1330541247.225:191): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=cgroup reason=allow vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 cgroup="/sys/fs/cgroup/devices/libvirt/qemu/Windows7/" class=path path=/dev/full rdev=01:07 acl=rw: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success' type=VIRT_RESOURCE msg=audit(1330541247.225:192): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=cgroup reason=allow vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 cgroup="/sys/fs/cgroup/devices/libvirt/qemu/Windows7/" class=path path=/dev/zero rdev=01:05 acl=rw: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success' type=VIRT_RESOURCE msg=audit(1330541247.225:193): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=cgroup reason=allow vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 cgroup="/sys/fs/cgroup/devices/libvirt/qemu/Windows7/" class=path path=/dev/random rdev=01:08 acl=rw: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success' type=VIRT_RESOURCE msg=audit(1330541247.225:194): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=cgroup reason=allow vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 cgroup="/sys/fs/cgroup/devices/libvirt/qemu/Windows7/" class=path path=/dev/urandom rdev=01:09 acl=rw: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success' type=VIRT_RESOURCE msg=audit(1330541247.225:195): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=cgroup reason=allow vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 cgroup="/sys/fs/cgroup/devices/libvirt/qemu/Windows7/" class=path path=/dev/ptmx rdev=05:02 acl=rw: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success' type=VIRT_RESOURCE msg=audit(1330541247.225:196): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=cgroup reason=allow vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 cgroup="/sys/fs/cgroup/devices/libvirt/qemu/Windows7/" class=path path=/dev/kvm rdev=? acl=rw: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=failed' type=VIRT_RESOURCE msg=audit(1330541247.225:197): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=cgroup reason=allow vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 cgroup="/sys/fs/cgroup/devices/libvirt/qemu/Windows7/" class=path path=/dev/kqemu rdev=? acl=rw: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=failed' type=VIRT_RESOURCE msg=audit(1330541247.226:198): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=cgroup reason=allow vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 cgroup="/sys/fs/cgroup/devices/libvirt/qemu/Windows7/" class=path path=/dev/rtc rdev=FE:00 acl=rw: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success' type=VIRT_RESOURCE msg=audit(1330541247.226:199): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=cgroup reason=allow vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 cgroup="/sys/fs/cgroup/devices/libvirt/qemu/Windows7/" class=path path=/dev/hpet rdev=0A:E4 acl=rw: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success' type=ANOM_PROMISCUOUS msg=audit(1330541247.250:200): dev=vnet0 prom=256 old_prom=0 auid=4294967295 uid=0 gid=0 ses=4294967295 type=SYSCALL msg=audit(1330541247.250:200): arch=c000003e syscall=16 success=yes exit=0 a0=17 a1=89a2 a2=7f9d40274ca0 a3=7 items=0 ppid=1 pid=1170 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) type=VIRT_RESOURCE msg=audit(1330541247.252:201): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=net reason=open vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 net='52:54:00:2C:7C:D2' path="/dev/net/tun" rdev=0A:C8: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success' type=AVC msg=audit(1330541247.303:202): avc: denied { execmem } for pid=30326 comm="qemu-system-x86" scontext=system_u:system_r:svirt_t:s0:c759,c959 tcontext=system_u:system_r:svirt_t:s0:c759,c959 tclass=process type=SYSCALL msg=audit(1330541247.303:202): arch=c000003e syscall=9 success=no exit=-13 a0=0 a1=32000000 a2=7 a3=62 items=0 ppid=1 pid=30326 auid=4294967295 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107 sgid=107 fsgid=107 tty=(none) ses=4294967295 comm="qemu-system-x86" exe="/usr/bin/qemu-system-x86_64" subj=system_u:system_r:svirt_t:s0:c759,c959 key=(null) type=ANOM_PROMISCUOUS msg=audit(1330541247.306:203): dev=vnet0 prom=0 old_prom=256 auid=4294967295 uid=107 gid=107 ses=4294967295 type=VIRT_RESOURCE msg=audit(1330541247.432:204): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=disk reason=start vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 old-disk="?" new-disk="/var/lib/libvirt/images/Windows7.img": exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success' type=VIRT_RESOURCE msg=audit(1330541247.432:205): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=net reason=start vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 old-net='?' new-net='52:54:00:2C:7C:D2': exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success' type=VIRT_RESOURCE msg=audit(1330541247.432:206): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=mem reason=start vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 old-mem=0 new-mem=4194304: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success' type=VIRT_RESOURCE msg=audit(1330541247.432:207): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=vcpu reason=start vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5 old-vcpu=0 new-vcpu=1: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success' type=VIRT_CONTROL msg=audit(1330541247.432:208): user pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu op=start reason=booted vm="Windows7" uuid=f6cddba1-b1ef-67d8-658b-e802d80352e5: exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=failed' BTW, I filed bug 798746 initially in libvirt group. I described the behaviour in more details there. Version-Release number of selected component (if applicable): -bash-4.2# rpm -qa | grep selin libselinux-python-2.1.6-6.fc16.x86_64 selinux-policy-targeted-3.10.0-75.fc16.noarch libselinux-2.1.6-6.fc16.x86_64 libselinux-2.1.6-6.fc16.i686 libselinux-utils-2.1.6-6.fc16.x86_64 selinux-policy-3.10.0-75.fc16.noarch How reproducible: Start virtual machine manager, select the guest machine and run. Steps to Reproduce: 1. Start the virtual machine manager 2. Select the guest machine need be started 3. Right click and select "run" Actual results: Received the above error messages. Expected results: The guest machine starts. Additional info: