Bug 1296640

Summary: Open vSwitch 2.5 needs new SElinux policy after introducing --user argument
Product: Red Hat Enterprise Linux 7 Reporter: Flavio Leitner <fleitner>
Component: selinux-policyAssignee: Lukas Vrabec <lvrabec>
Status: CLOSED ERRATA QA Contact: Milos Malik <mmalik>
Severity: high Docs Contact:
Priority: high    
Version: 7.3CC: aconole, ansisatteka, dwalsh, fleitner, lvrabec, mgrepl, mmalik, plautrba, pvrabec, rkhan, ssekidde
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: selinux-policy-3.13.1-69.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1295250
: 1330895 (view as bug list) Environment:
Last Closed: 2016-11-04 02:39:44 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1297820, 1317889    

Description Flavio Leitner 2016-01-07 17:39:07 UTC 
This is a clone for RHEL-7.2 to make sure the issue doesn't happen when 2.5 arrives.

+++ This bug was initially created as a clone of Bug #1295250 +++

Description of problem:

In OVS (Open vSwitch) 2.5 we are about to introduce a new feature where all ovs-* daemons would be running under "openvswitch" instead of "root" Linux user.  However, current Open vSwitch SElinux policy is too strict and does not allow to use this --user feature (see below why).



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

Verified on Fedora 23 with default configuration and Open vSwitch 2.5 (from GIT repository + Patch http://openvswitch.org/pipermail/dev/2015-November/062367.html).



How reproducible:

100% of the time.



Steps to Reproduce:
1. Build Open vSwitch 2.5 with --user support (needs the patch above)
2. systemctl start openvswitch
3. observe that SElinux prevented Open vSwitch from starting up.



Actual results:

If SElinux is in enforcing mode (the default) then it prevents Open vSwitch from starting up.



Expected results:

Open vSwitch should also be able to run under SElinux enforcing mode that is being used by default.




Additional info:

I am an Open vSwitch developer and encountered this bug while testing the --user feature on Fedora and CentOS. Here is the SElinux *.te file that workarunded my issue:


module mypol 1.0;

require {
        type openvswitch_t;
        class process setcap;
        class capability { dac_override setpcap setuid setgid chown};
}

#============= openvswitch_t ==============
allow openvswitch_t self:capability { dac_override setpcap setgid chown setuid};
allow openvswitch_t self:process setcap;
Comment 1 Aaron Conole 2016-01-11 22:47:58 UTC 
I've set my system to setenforce Permissive, and collected a log.

type=AVC msg=audit(1452552156.996:171): avc:  denied  { dac_override } for  pid=
74978 comm="ovsdb-server" capability=1  scontext=system_u:system_r:openvswitch_t
:s0 tcontext=system_u:system_r:openvswitch_t:s0 tclass=capability
type=SYSCALL msg=audit(1452552156.996:171): arch=c000003e syscall=2 success=yes 
exit=5 a0=7d3a60 a1=441 a2=1b6 a3=7fff343461b0 items=0 ppid=74963 pid=74978 auid
=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) s
es=4294967295 comm="ovsdb-server" exe="/usr/sbin/ovsdb-server" subj=system_u:sys
tem_r:openvswitch_t:s0 key=(null)
type=AVC msg=audit(1452552156.996:172): avc:  denied  { chown } for  pid=74978 comm="ovsdb-server" capability=0  scontext=system_u:system_r:openvswitch_t:s0 tcontext=system_u:system_r:openvswitch_t:s0 tclass=capability
type=SYSCALL msg=audit(1452552156.996:172): arch=c000003e syscall=92 success=yes exit=0 a0=7d3420 a1=3e9 a2=3e9 a3=7fff343462a0 items=0 ppid=74963 pid=74978 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="ovsdb-server" exe="/usr/sbin/ovsdb-server" subj=system_u:system_r:openvswitch_t:s0 key=(null)
type=AVC msg=audit(1452552156.996:173): avc:  denied  { setcap } for  pid=74978 comm="ovsdb-server" scontext=system_u:system_r:openvswitch_t:s0 tcontext=system_u:system_r:openvswitch_t:s0 tclass=process
type=SYSCALL msg=audit(1452552156.996:173): arch=c000003e syscall=126 success=yes exit=0 a0=7f73dc49082c a1=7f73dc490834 a2=0 a3=7fff34346250 items=0 ppid=74963 pid=74978 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="ovsdb-server" exe="/usr/sbin/ovsdb-server" subj=system_u:system_r:openvswitch_t:s0 key=(null)
type=AVC msg=audit(1452552156.997:174): avc:  denied  { setpcap } for  pid=74978 comm="ovsdb-server" capability=8  scontext=system_u:system_r:openvswitch_t:s0 tcontext=system_u:system_r:openvswitch_t:s0 tclass=capability
type=SYSCALL msg=audit(1452552156.997:174): arch=c000003e syscall=157 success=yes exit=0 a0=18 a1=0 a2=0 a3=0 items=0 ppid=74963 pid=74978 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="ovsdb-server" exe="/usr/sbin/ovsdb-server" subj=system_u:system_r:openvswitch_t:s0 key=(null)
type=AVC msg=audit(1452552156.997:175): avc:  denied  { setgid } for  pid=74978 comm="ovsdb-server" capability=6  scontext=system_u:system_r:openvswitch_t:s0 tcontext=system_u:system_r:openvswitch_t:s0 tclass=capability
type=SYSCALL msg=audit(1452552156.997:175): arch=c000003e syscall=119 success=yes exit=0 a0=3e9 a1=3e9 a2=3e9 a3=7f73dba282e0 items=0 ppid=74963 pid=74978 auid=4294967295 uid=0 gid=1001 euid=0 suid=0 fsuid=0 egid=1001 sgid=1001 fsgid=1001 tty=(none) ses=4294967295 comm="ovsdb-server" exe="/usr/sbin/ovsdb-server" subj=system_u:system_r:openvswitch_t:s0 key=(null)
type=AVC msg=audit(1452552156.997:176): avc:  denied  { setuid } for  pid=74978 comm="ovsdb-server" capability=7  scontext=system_u:system_r:openvswitch_t:s0 tcontext=system_u:system_r:openvswitch_t:s0 tclass=capability
type=SYSCALL msg=audit(1452552156.997:176): arch=c000003e syscall=117 success=yes exit=0 a0=3e9 a1=3e9 a2=3e9 a3=7f73dba282e0 items=0 ppid=74963 pid=74978 auid=4294967295 uid=1001 gid=1001 euid=1001 suid=1001 fsuid=1001 egid=1001 sgid=1001 fsgid=1001 tty=(none) ses=4294967295 comm="ovsdb-server" exe="/usr/sbin/ovsdb-server" subj=system_u:system_r:openvswitch_t:s0 key=(null)
type=AVC msg=audit(1452552156.998:177): avc:  denied  { create } for  pid=74980 comm="ovsdb-server" name="db.sock" scontext=system_u:system_r:openvswitch_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file
type=SYSCALL msg=audit(1452552156.998:177): arch=c000003e syscall=49 success=yes exit=0 a0=10 a1=7fff343462f0 a2=1f a3=7fff34345ff0 items=0 ppid=74979 pid=74980 auid=4294967295 uid=1001 gid=1001 euid=1001 suid=1001 fsuid=1001 egid=1001 sgid=1001 fsgid=1001 tty=(none) ses=4294967295 comm="ovsdb-server" exe="/usr/sbin/ovsdb-server" subj=system_u:system_r:openvswitch_t:s0 key=(null)
type=AVC msg=audit(1452552157.002:178): avc:  denied  { write } for  pid=74981 comm="ovs-vsctl" name="db.sock" dev="tmpfs" ino=145401 scontext=system_u:system_r:openvswitch_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file
type=SYSCALL msg=audit(1452552157.002:178): arch=c000003e syscall=42 success=yes exit=0 a0=4 a1=7ffc08910520 a2=1f a3=ffffffff items=0 ppid=74963 pid=74981 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="ovs-vsctl" exe="/usr/bin/ovs-vsctl" subj=system_u:system_r:openvswitch_t:s0 key=(null)
type=SERVICE_START msg=audit(1452552157.029:179): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=openvswitch-nonetwork comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=SERVICE_START msg=audit(1452552157.033:180): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=openvswitch comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

What you have should work. NOTE: for this test, instead of applying the patch to the startup scripts I manually created the directory and edited ovs-ctl directly to just use --user flag. I can repeat with the supplied patch, as well, but I don't know if it's needed.
Comment 5 Flavio Leitner 2016-08-25 04:26:23 UTC 
Aaron,
Could you please help Milos? I don't think we have a package with that enabled yet, so most probably it will be started manually.  Perhaps we can provide a recipe?
Comment 8 errata-xmlrpc 2016-11-04 02:39:44 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.

https://rhn.redhat.com/errata/RHBA-2016-2283.html