Description of problem: I have a rhel4 full-virt. guest setup with it's storage backed by the /dev/vg1/rhel4 LV. On domain creation, I'm getting a SELinux denied the access of ifconfig to access /dev/vg1/rhel4?!?!?!?!? Version-Release number of selected component (if applicable): net-tools-1.60-73 xen-3.0.3-25.0.3.el5 How reproducible: every time Steps to Reproduce: 1. Setup a full-virt guest backed by a LV 2. xm create <name> Actual results: Domain is created, access is denied for ifconfig to the guests storage device. Expected results: Domain is created, no access is needed to a block device by ifconfig. Additional info: avc: denied { read, write } for comm="ifconfig" dev=tmpfs egid=0 euid=0 exe="/sbin/ifconfig" exit=0 fsgid=0 fsuid=0 gid=0 items=0 name="vg1-rhel4" path="/dev/mapper/vg1-rhel4" pid=4715 scontext=system_u:system_r:ifconfig_t:s0 sgid=0 subj=system_u:system_r:ifconfig_t:s0 suid=0 tclass=blk_file tcontext=system_u:object_r:fixed_disk_device_t:s0 tty=(none) uid=0
Created attachment 154841 [details] Wrapper script to run strace against /sbin/ifconfig.real
Created attachment 154842 [details] Trace of ifconfig made using the attached wrapper. Had to relabel the wrapper script, but using it did produce the same AVC denial warning.
Does this cause the xen guest to fail? Or are you just seeing an AVC message?
As far as I can tell the guest starts up and runs fine. It cannot access the network since dom0's iptables rh-firewall-1 is up, but that's another bug (vif-common.sh appends rule instead of inserting it at top). So, the only thing I'm being bothered with is the AVC message. What really concerns me isn't the xen stuff here, it's the fact that ifconfig is trying to access the block device in the first place. Not sure if this is an ifconfig problem or a xm/xen problem.
This is a leaked file descriptor from xen. xen has an open file descriptor to the fixed device and when it execs the ifconfig script, the program transitions to the other domain. When an SELinux kernel starts to transition and executable, it checks the access of all open file descriptors, in this case generating avc messages. The kernel then closes the file descriptors and continues with the execution. So this is really a xen problem.
This is fixed in RHEL-5.1 RPMs. *** This bug has been marked as a duplicate of 230790 ***