RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 843543 - starting libvirt default network causes avc: denied { write } comm="dnsmasq" scontext=unconfined_u:system_r:dnsmasq_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:virt_var_run_t:s0 tclass=dir
Summary: starting libvirt default network causes avc: denied { write } comm="dnsmasq...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy
Version: 6.3
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Miroslav Grepl
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-07-26 15:00 UTC by Paolo Bonzini
Modified: 2013-02-21 08:26 UTC (History)
15 users (show)

Fixed In Version: selinux-policy-3.7.19-190.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-21 08:26:14 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0314 0 normal SHIPPED_LIVE selinux-policy bug fix and enhancement update 2013-02-20 20:35:01 UTC

Description Paolo Bonzini 2012-07-26 15:00:29 UTC
Description of problem:
libvirt starts dnsmasq with --pid-file=/var/run/libvirt/network/default.pid but dnsmasq cannot write to virt_var_run_t

# ls -Z /var/run/libvirt/network/
-rw-r--r--. root root unconfined_u:object_r:virt_var_run_t:s0 default.pid
-rw-r--r--. root root unconfined_u:object_r:virt_var_run_t:s0 nwfilter.leases

Version-Release number of selected component (if applicable):
0.9.13-3.el6

How reproducible:
100%

Steps to Reproduce:
  yum install libvirt
  service libvirtd start
  virsh net-start default
  
Actual results:
Starting default network fails.

Expected results:
Starting default network works.

Additional info:
This error is also logged, will file a separate bug:

type=SELINUX_ERR msg=audit(1343312370.260:393): security_compute_sid:  invalid context unconfined_u:unconfined_r:iptables_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:virtd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=process

Comment 2 Miroslav Grepl 2012-07-26 17:58:54 UTC
We have two issues. Could you try to execute

# restorecon -R -v /var/run/libvirt/network/
# echo "type=SELINUX_ERR msg=audit(1343312370.260:393): security_compute_sid:  invalid context unconfined_u:unconfined_r:iptables_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:virtd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=process" | audit2allow -M mypol
# semodule -i mypol.pp


The problem is we have 

virtd_t running as unconfined_r which does a transition to iptables_t.

Comment 3 Paolo Bonzini 2012-07-27 07:52:55 UTC
Restoring the contexts worked.  I'm a bit puzzled as to why a normal installation of libvirt created wrong contexts, which is why I reported a separate bug for the transitions (bug 843544).

Regarding the transitions, I also see these in permissive mode:

type=SELINUX_ERR msg=audit(1343312811.896:525): security_compute_sid:  invalid context unconfined_u:unconfined_r:dmidecode_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:virtd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dmidecode_exec_t:s0 tclass=process
type=SELINUX_ERR msg=audit(1343312811.732:520): security_compute_sid:  invalid context unconfined_u:unconfined_r:dnsmasq_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:virtd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dnsmasq_exec_t:s0 tclass=process

In enforcing mode, dnsmasq is not launched because of the iptables problem.  After doing the steps in comment 2, a "strace -ff -e execve libvirtd -v" indeed shows dnsmasq still failing to start:

[pid 28089] execve("/usr/sbin/dnsmasq", ["/usr/sbin/dnsmasq", "--strict-order", "--bind-interfaces", "--pid-file=/var/run/libvirt/netw"..., "--conf-file=", "--except-interface", "lo", "--listen-address", "192.168.122.1", "--dhcp-range", "192.168.122.2,192.168.122.254", "--dhcp-leasefile=/var/lib/libvir"..., "--dhcp-lease-max=253", "--dhcp-no-override"], [/* 34 vars */]) = -1 EACCES (Permission denied)
execve("/usr/sbin/dmidecode", ["/usr/sbin/dmidecode", "-q", "-t", "0,1,4,17"], [/* 34 vars */]) = -1 EACCES (Permission denied)

So we need all of these:

module mypol 1.0;

require {
	type dmidecode_t;
	type iptables_t;
	type dnsmasq_t;
	role unconfined_r;
}

#============= ROLES ==============
role unconfined_r types dmidecode_t;
role unconfined_r types iptables_t;
role unconfined_r types dnsmasq_t;

Comment 4 Daniel Walsh 2012-07-31 15:56:51 UTC
We should eliminate the transition from unconfined_t to svirt_t. like we have in Fedora.

Comment 5 Miroslav Grepl 2012-08-01 08:15:11 UTC
Yes, I removed it.

Comment 6 Miroslav Grepl 2012-08-07 23:43:25 UTC
Fixed in selinux-policy-3.7.19-159.el6

Comment 10 Jeff Burke 2012-10-30 14:40:48 UTC
With selinux-policy-3.7.19-172.el6 We are seeing this AVC Denied message:

time->Mon Oct 29 14:16:57 2012
type=SYSCALL msg=audit(1351534617.890:66): arch=c000003e syscall=2 success=no exit=-13 a0=170eaf0 a1=241 a2=1b6 a3=0 items=0 ppid=1 pid=7367 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="dnsmasq" exe="/usr/sbin/dnsmasq" subj=unconfined_u:system_r:dnsmasq_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1351534617.890:66): avc:  denied  { write } for  pid=7367 comm="dnsmasq" name="network" dev=dm-0 ino=1443806 scontext=unconfined_u:system_r:dnsmasq_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_var_run_t:s0 tclass=dir

Regards,
Jeff

Comment 13 Daniel Walsh 2012-10-30 20:13:33 UTC
I believe the network directory has a wrong label on it.

DOes 

restorecon -R -v /var/run 

Fix it?

Comment 14 Jeff Burke 2012-10-31 12:27:28 UTC
Dan,
 Not I am not 100% sure as this is seen in automated testing. If in fact it is mislabled then it is being done so at install time. I can try and stop the test before it gets to that point in testing and relabel the directory.

Regards,
Jeff

Comment 15 Daniel Walsh 2012-10-31 13:44:15 UTC
Miroslav, I think for RHEL6 we will just have to allow this, since I am not sure we can get this directory labeled correctly.

Comment 19 Daniel Walsh 2012-12-11 20:05:05 UTC
Is this a labeling problem under /var/run?

restorecon -R -v /var/run

Comment 20 Miroslav Grepl 2013-01-03 15:48:42 UTC
(In reply to comment #15)
> Miroslav, I think for RHEL6 we will just have to allow this, since I am not
> sure we can get this directory labeled correctly.

I believe we need to allow it also for dhcpc_t.

Comment 21 Daniel Walsh 2013-01-03 16:48:38 UTC
Fine.

Comment 24 errata-xmlrpc 2013-02-21 08:26:14 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0314.html


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