Bug 984453 - fence_xvm not working when SELinux is enforcing (even though fenced_can_network_connect is on)
fence_xvm not working when SELinux is enforcing (even though fenced_can_netwo...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: selinux-policy (Show other bugs)
5.10
All Linux
high Severity unspecified
: rc
: ---
Assigned To: Miroslav Grepl
Milos Malik
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-15 05:44 EDT by Jaroslav Kortus
Modified: 2014-09-15 20:29 EDT (History)
3 users (show)

See Also:
Fixed In Version: selinux-policy-2.4.6-347.el5
Doc Type: Bug Fix
Doc Text:
Previously, SELinux prevented the fence_xvm agent from fencing nodes even if the fenced_can_network_connect Boolean was enabled. The SELinux policy has been modified to fix this bug and SELinux no longer blocks fence_xvm in the described scenario.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-09-15 20:29:46 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jaroslav Kortus 2013-07-15 05:44:32 EDT
Description of problem:
fence_xvm not working with selinux enforcing (even though fenced_can_network_connect is on).

Related denial:
type=AVC msg=audit(1373880998.461:141): avc:  denied  { name_bind } for  pid=4664 comm="fence_xvm" src=1229 scontext=root:system_r:fenced_t:s0-s0:c0.c1023 tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket
type=SYSCALL msg=audit(1373880998.461:141): arch=c000003e syscall=49 success=no exit=-13 a0=5 a1=7fffae64de70 a2=10 a3=7fffae64de6c items=0 ppid=5681 pid=4664 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="fence_xvm" exe="/sbin/fence_xvm" subj=root:system_r:fenced_t:s0-s0:c0.c1023 key=(null)

Jul 15 11:36:38 virt-061 fenced[5681]: agent "fence_xvm" reports: Failed to listen: Permission denied

The agent binds to port 1229/tcp to get the connection from fence_virtd. This is denied, therefore the action itself fails.

I suggest following modifications:
1. put a label on 1229 port so it's not prot_t (inspire by rhel6 here where it's zented_port_t)
2. put binding to this port tunable for fenced_t by fenced_can_network_connect
3. allow transitions to fenced_t from unconfined_t so that "runcon -t fenced_t bash" does not fail on transition denial (helps debugging in different contexts)



Version-Release number of selected component (if applicable):
selinux-policy-2.4.6-344.el5

How reproducible:
100%

Steps to Reproduce:
1. set up cluster with virtual fencing (fence_virtd+fence_xvm)
2. enable fenced_can_network_connect
3. kill one node

Actual results:
The node cannot be fenced due to selinux denial

Expected results:
Node fenced, fence_xvm able to bind to 1229/tcp port in fenced_t context

Additional info:
Comment 1 RHEL Product and Program Management 2013-07-15 11:05:42 EDT
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux release.  Product Management has
requested further review of this request by Red Hat Engineering, for
potential inclusion in a Red Hat Enterprise Linux release for currently
deployed products.  This request is not yet committed for inclusion in
a release.
Comment 2 RHEL Product and Program Management 2013-07-24 00:03:34 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 7 errata-xmlrpc 2014-09-15 20:29:46 EDT
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-2014-1205.html

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