Bug 811319 - fence_virtd runs as initrc_t
fence_virtd runs as initrc_t
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy (Show other bugs)
All Linux
medium Severity medium
: rc
: ---
Assigned To: Miroslav Grepl
Milos Malik
Depends On:
Blocks: 832330 870602
  Show dependency treegraph
Reported: 2012-04-10 13:37 EDT by Milos Malik
Modified: 2013-02-21 03:35 EST (History)
6 users (show)

See Also:
Fixed In Version: selinux-policy-3.7.19-185.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 870602 (view as bug list)
Last Closed: 2013-02-21 03:35:13 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Milos Malik 2012-04-10 13:37:37 EDT
Description of problem:

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
# run_init service fence_virtd status
Authenticating root.
fence_virtd is stopped
# run_init service fence_virtd start
Authenticating root.
Starting fence_virtd:                                      [  OK  ]
# run_init service fence_virtd status
Authenticating root.
fence_virtd (pid  12627) is running...
# ps -efZ | grep fence_virtd
system_u:system_r:initrc_t:s0   root     12627     1  0 19:36 ?        00:00:00 /usr/sbin/fence_virtd -w
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 12642 12100  0 19:36 pts/1 00:00:00 grep fence_virtd

Actual results:
* fence_virtd runs as initrc_t

Expected results:
* fence_virtd runs in its own SELinux domain
Comment 1 Milos Malik 2012-04-10 16:41:31 EDT
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?
Comment 2 RHEL Product and Program Management 2012-07-10 04:07:28 EDT
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.
Comment 3 RHEL Product and Program Management 2012-07-10 19:12:43 EDT
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.
Comment 5 Daniel Walsh 2012-08-01 16:09:06 EDT
We could label it virsh_exec_t if its job is to configure libvirt.
Comment 6 Miroslav Grepl 2012-08-29 05:00:51 EDT
could you test it with

# chcon -t virsh_exec_t /usr/sbin/fence_virtd

to see if virsh_t domain is enough. Thank you.
Comment 7 Marek Grac 2012-09-24 08:38:46 EDT

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)
Comment 8 Miroslav Grepl 2012-09-27 12:57:37 EDT
is there a machine where I could test it?
Comment 9 Marek Grac 2012-10-01 04:30:51 EDT
Sorry, I have it installed only on my laptop but you don't need cluster, just machine + virtual machine.
Comment 10 Miroslav Grepl 2012-10-09 07:59:27 EDT
I added some fixes to selinux-policy-3.7.19-168.el6 to see if it fixes this issue.
Comment 13 Nate Straz 2012-11-12 11:21:10 EST
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:

    <fencedevice name="xvm" agent="fence_xvm" auth="sha256" hash="sha256" key_file="/etc/cluster/fence_xvm.key" timeout="5"/>
Comment 14 Nate Straz 2012-11-12 12:08:00 EST
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
Comment 15 Daniel Walsh 2012-11-12 14:46:33 EST
I just checked in fixes for this in F18 policy.
Comment 17 Nate Straz 2012-12-03 12:07:46 EST
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 (
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
Comment 18 Jaroslav Kortus 2012-12-03 12:18:35 EST
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.
Comment 19 Miroslav Grepl 2012-12-04 10:02:05 EST
We have this rule in Fedora. Backporting it.
Comment 21 errata-xmlrpc 2013-02-21 03:35:13 EST
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.


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