The daemon is not confined by SELinux. Please help SELinux folks to create a suitable policy module. You know that we should minimize the number of programs running as initrc_t, don't you?

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

We could label it virsh_exec_t if its job is to configure libvirt.

Lon,
could you test it with

# chcon -t virsh_exec_t /usr/sbin/fence_virtd

to see if virsh_t domain is enough. Thank you.

@mgrepl:

Unit test:

1. run_init fence_virtd start
2. fence_xvm -o list (on same machine)

expected output: show available machines for fencing
current output: none

---
when running in enforcing mode after change proposed in comment#6


type=AVC msg=audit(1348489652.069:657): avc:  denied  { write } for  pid=6851 comm="fence_virtd" name="/" dev="tmpfs" ino=1198 scontext=system_u:system_r:virsh_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=dir
type=SYSCALL msg=audit(1348489652.069:657): arch=c000003e syscall=2 success=no exit=-13 a0=60a5c0 a1=241 a2=1b6 a3=238 items=0 ppid=6850 pid=6851 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="fence_virtd" exe="/usr/sbin/fence_virtd" subj=system_u:system_r:virsh_t:s0 key=(null)

Marek,
is there a machine where I could test it?

Sorry, I have it installed only on my laptop but you don't need cluster, just machine + virtual machine.

I added some fixes to selinux-policy-3.7.19-168.el6 to see if it fixes this issue.

Fencing using fence_xvm and fence_virtd is failing because of AVCs.

type=AVC msg=audit(1352731332.558:121851): avc:  denied  { getattr } for  pid=544 comm="fence_virtd" path="/usr/sbin/libvirtd" dev=dm-0 ino=2241942 scontext=unconfined_u:system_r:fenced_t:s0 tcontext=system_u:object_r:virtd_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1352731332.558:121851): arch=c000003e syscall=4 success=no exit=-13 a0=3f8cdd5830 a1=7fffe7ff79e0 a2=7fffe7ff79e0 a3=75722f7261762f20 items=0 ppid=1 pid=544 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=157 comm="fence_virtd" exe="/usr/sbin/fence_virtd" subj=unconfined_u:system_r:fenced_t:s0 key=(null)

Cluster config snippet:

  <fencedevices>
    <fencedevice name="xvm" agent="fence_xvm" auth="sha256" hash="sha256" key_file="/etc/cluster/fence_xvm.key" timeout="5"/>
  </fencedevices>

Additional AVCs hit while adding audit2allow generated rules:

type=AVC msg=audit(1352739133.132:123531): avc:  denied  { getattr } for  pid=544 comm="fence_virtd" path="/usr/sbin/libvirtd" dev=dm-0 ino=2241942 scontext=unconfined_u:system_r:fenced_t:s0 tcontext=system_u:object_r:virtd_exec_t:s0 tclass=file

type=AVC msg=audit(1352739213.140:123567): avc:  denied  { write } for  pid=544 comm="fence_virtd" name="libvirt-sock" dev=dm-0 ino=3017442 scontext=unconfined_u:system_r:fenced_t:s0 tcontext=unconfined_u:object_r:virt_var_run_t:s0 tclass=sock_file

type=AVC msg=audit(1352739263.147:123578): avc:  denied  { connectto } for  pid=544 comm="fence_virtd" path="/var/run/libvirt/libvirt-sock" scontext=unconfined_u:system_r:fenced_t:s0 tcontext=unconfined_u:system_r:virtd_t:s0-s0:c0.c1023 tclass=unix_stream_socket

I just checked in fixes for this in F18 policy.

I think there might be a problem with the fix.  I'm not getting any AVC denials, but I am having a hard time getting fence_virtd to start.  When started by hand it starts, but that's running in unconfined_t.  If I start it with the `service` command it dies.  I added debugging and found that it wasn't able to bind.

Setting up ipv4 multicast receive (225.0.0.12:1229)
bind failed: Permission denied
Could not set up multicast listen socket

I think there may be something wrong with the rules.

Found 6 semantic av rules:
   allow fenced_t zented_port_t : tcp_socket name_bind ;
   allow fenced_t ionixnetmon_port_t : udp_socket name_bind ;
   allow fenced_t port_t : tcp_socket { name_bind name_connect } ;
   allow fenced_t port_t : udp_socket name_bind ;
   allow fenced_t rpc_port_type : tcp_socket name_bind ;
   allow fenced_t rpc_port_type : udp_socket name_bind ;

fence_virtd is attempting to bind to 1229 w/ udp.  It appears the udp rule is for the wrong port, 7410.

# rpm -q selinux-policy
selinux-policy-3.7.19-181.el6.noarch

I got this denial:
type=SYSCALL msg=audit(1354554415.649:74781): arch=c000003e syscall=49 success=yes exit=0 a0=7 a1=7fffe25aed40 a2=10 a3=0 items=0 ppid=1 pid=8065 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) )
type=AVC msg=audit(1354554415.649:74781): avc:  denied  { name_bind } for  pid=8065 comm="fence_virtd" src=1229 scontext=unconfined_u:system_r:fenced_t:s0 tcontext=system_u:object_r:zented_port_t:s0 tclass=udp_socket

with selinux-policy-3.7.19-181.el6.noarch.

We have this rule in Fedora. Backporting it.

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