Bug 1440412 - learn-address don't work during selinux restrictions
Summary: learn-address don't work during selinux restrictions
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: openvpn
Version: epel7
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: David Sommerseth
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 982958 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-04-08 16:13 UTC by Frank Büttner
Modified: 2018-02-16 20:21 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2018-02-16 20:15:56 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
The used script. (330 bytes, application/x-shellscript)
2017-04-08 16:13 UTC, Frank Büttner
no flags Details

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. ***


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