Bug 1440412

Summary: learn-address don't work during selinux restrictions
Product: [Fedora] Fedora EPEL Reporter: Frank Büttner <bugzilla>
Component: openvpnAssignee: David Sommerseth <dazo>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: epel7CC: dazo, huzaifas, mauricio.teixeira, mgrepl, steve
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-02-16 20:15:56 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:
Attachments:
Description Flags
The used script. none

Description Frank Büttner 2017-04-08 16:13:44 UTC
Created attachment 1270052 [details]
The used script.

Description of problem:
When I try to use the learn-address option, the call of the script will fail.

Version-Release number of selected component (if applicable):
openvpn-2.3.14-1.el7.x86_64

How reproducible:
Every time

Steps to Reproduce:
1. start the server
2. wait for an client connect 
3.

Actual results:
The fails, with an selinux denied error.

Expected results:
Working script


Additional info:
ype=AVC msg=audit(1491667162.782:121697): avc:  denied  { execute } for  pid=14324 comm="ipv6-routing" name="sudo" dev="vda2" ino=792096 scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1491667162.782:121697): arch=c000003e syscall=59 success=no exit=-13 a0=febed0 a1=fe8be0 a2=fe8720 a3=7fffefd895d0 items=0 ppid=14323 pid=14324 auid=4294967295 uid=481 gid=481 euid=481 suid=481 fsuid=481 egid=481 sgid=481 fsgid=481 tty=(none) ses=4294967295 comm="ipv6-routing" exe="/usr/bin/bash" subj=system_u:system_r:openvpn_t:s0 key=(null)
type=AVC msg=audit(1491667162.783:121698): avc:  denied  { getattr } for  pid=14324 comm="ipv6-routing" path="/usr/bin/sudo" dev="vda2" ino=792096 scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1491667162.783:121698): arch=c000003e syscall=4 success=no exit=-13 a0=febed0 a1=7fffefd897a0 a2=7fffefd897a0 a3=7fffefd89520 items=0 ppid=14323 pid=14324 auid=4294967295 uid=481 gid=481 euid=481 suid=481 fsuid=481 egid=481 sgid=481 fsgid=481 tty=(none) ses=4294967295 comm="ipv6-routing" exe="/usr/bin/bash" subj=system_u:system_r:openvpn_t:s0 key=(null)
type=AVC msg=audit(1491667162.783:121699): avc:  denied  { getattr } for  pid=14324 comm="ipv6-routing" path="/usr/bin/sudo" dev="vda2" ino=792096 scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1491667162.783:121699): arch=c000003e syscall=4 success=no exit=-13 a0=febed0 a1=7fffefd89780 a2=7fffefd89780 a3=7fffefd89520 items=0 ppid=14323 pid=14324 auid=4294967295 uid=481 gid=481 euid=481 suid=481 fsuid=481 egid=481 sgid=481 fsgid=481 tty=(none) ses=4294967295 comm="ipv6-routing" exe="/usr/bin/bash" subj=system_u:system_r:openvpn_t:s0 key=(null)
type=AVC msg=audit(1491667437.711:121731): avc:  denied  { execute } for  pid=14428 comm="ipv6-routing" name="sudo" dev="vda2" ino=792096 scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1491667437.711:121731): arch=c000003e syscall=59 success=no exit=-13 a0=17e3eb0 a1=17e0be0 a2=17e0720 a3=7ffd522ccc10 items=0 ppid=14427 pid=14428 auid=4294967295 uid=481 gid=481 euid=481 suid=481 fsuid=481 egid=481 sgid=481 fsgid=481 tty=(none) ses=4294967295 comm="ipv6-routing" exe="/usr/bin/bash" subj=system_u:system_r:openvpn_t:s0 key=(null)
type=AVC msg=audit(1491667437.711:121732): avc:  denied  { getattr } for  pid=14428 comm="ipv6-routing" path="/usr/bin/sudo" dev="vda2" ino=792096 scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1491667437.711:121732): arch=c000003e syscall=4 success=no exit=-13 a0=17e3eb0 a1=7ffd522ccde0 a2=7ffd522ccde0 a3=7ffd522ccb60 items=0 ppid=14427 pid=14428 auid=4294967295 uid=481 gid=481 euid=481 suid=481 fsuid=481 egid=481 sgid=481 fsgid=481 tty=(none) ses=4294967295 comm="ipv6-routing" exe="/usr/bin/bash" subj=system_u:system_r:openvpn_t:s0 key=(null)
type=AVC msg=audit(1491667437.711:121733): avc:  denied  { getattr } for  pid=14428 comm="ipv6-routing" path="/usr/bin/sudo" dev="vda2" ino=792096 scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1491667437.711:121733): arch=c000003e syscall=4 success=no exit=-13 a0=17e3eb0 a1=7ffd522ccdc0 a2=7ffd522ccdc0 a3=7ffd522ccb60 items=0 ppid=14427 pid=14428 auid=4294967295 uid=481 gid=481 euid=481 suid=481 fsuid=481 egid=481 sgid=481 fsgid=481 tty=(none) ses=4294967295 comm="ipv6-routing" exe="/usr/bin/bash" subj=system_u:system_r:openvpn_t:s0 key=(null)

Comment 1 David Sommerseth 2018-02-16 20:15:56 UTC
The reason is simply that the openvpn_t context (which the OpenVPN process runs as, as it is labelled openvpn_exec_t) is not allowed to run sudo_exec_t labelled executables.  Which is highly security related.

By passing the audit you have extracted through audit2allow, you get this proposed SELinux module:

    allow openvpn_t sudo_exec_t:file { execute getattr };

(you might need a few more privileges as well, once these can be executed).

There is also a SELinux boolean which can be considered.  It will probably not make that much difference to allow this or to allow openvpn_t to run sudo_exec_t, from a security perspective.  I'd try that first, before playing with SELinux modules.

# semanage boolean --list | grep openvpn_run
openvpn_run_unconfined         (off  ,  off)  Allow openvpn to run unconfined


To make something which is a lot more safer will require to write a simple daemon which runs in parallel with at least proper CAP_NETADMIN privileges (which should be allowed to do 'ip neigh' operations).  And the --learn-address script would need to communicate $action and $addr to this script through some socket, d-bus or similar IPC mechanisms.  This way you will have a proper privilege separation between OpenVPN and the process changing the network configuration.


As SELinux and other security mechanisms evolve, the script hooks in OpenVPN will just be harder and harder to use.  Simply because they are fairly insecure.  It's a very different world today compared to how it was just 10 years ago.  And it isn't something which is really possible to fix in OpenVPN 2.x natively.

The whole script-hook feature needs to be re-implemented using more modern and more secure approaches - like using D-Bus to trigger script execution for example.  And that needs to be handled upstream, not in the Fedora/EPEL package.  So closing this as WONTFIX.

Comment 2 David Sommerseth 2018-02-16 20:21:52 UTC
*** Bug 982958 has been marked as a duplicate of this bug. ***