Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 979432 - SELinux forbids iptables(1) calls from OpenVPN client-(dis)connect scripts
SELinux forbids iptables(1) calls from OpenVPN client-(dis)connect scripts
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy (Show other bugs)
6.4
All Linux
medium Severity medium
: rc
: ---
Assigned To: Miroslav Grepl
Michal Trunecka
:
Depends On:
Blocks: 982958
  Show dependency treegraph
 
Reported: 2013-06-28 09:53 EDT by Robert Scheck
Modified: 2014-09-30 19:35 EDT (History)
7 users (show)

See Also:
Fixed In Version: selinux-policy-3.7.19-210.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 982958 (view as bug list)
Environment:
Last Closed: 2013-11-21 05:32:05 EST
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)
uncofined scripts support to openvpn (1.78 KB, patch)
2013-07-09 17:07 EDT, Daniel Walsh
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:1598 normal SHIPPED_LIVE selinux-policy bug fix and enhancement update 2013-11-20 16:39:24 EST

  None (edit)
Description Robert Scheck 2013-06-28 09:53:39 EDT
Description of problem:
SELinux forbids iptables(1) calls from OpenVPN client-(dis)connect scripts:

type=AVC msg=audit(1372360310.427:588674): avc:  denied  { create } for  pid=26457 comm="iptables" scontext=unconfined_u:system_r:openvpn_t:s0 tcontext=unconfined_u:system_r:openvpn_t:s0 tclass=rawip_socket
type=SYSCALL msg=audit(1372360310.427:588674): arch=x86_64 syscall=socket success=no exit=EACCES a0=2 a1=3 a2=ff a3=4 items=0 ppid=26455 pid=26457 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=29397 comm=iptables exe=/sbin/iptables-multi-1.4.7 subj=unconfined_u:system_r:openvpn_t:s0 key=(null)

type=AVC msg=audit(1372360310.427:588675): avc:  denied  { read } for  pid=26457 comm="iptables" scontext=unconfined_u:system_r:openvpn_t:s0 tcontext=system_u:object_r:sysctl_modprobe_t:s0 tclass=file
type=SYSCALL msg=audit(1372360310.427:588675): arch=x86_64 syscall=open success=no exit=EACCES a0=37cac05672 a1=0 a2=0 a3=4 items=0 ppid=26455 pid=26457 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=29397 comm=iptables exe=/sbin/iptables-multi-1.4.7 subj=unconfined_u:system_r:openvpn_t:s0 key=(null)

For me this feels a bit like we need a openvpn_exec_iptables SELinux boolean?!

Version-Release number of selected component (if applicable):
openvpn-2.3.1-3.el6.x86_64
selinux-policy-targeted-3.7.19-195.el6_4.10.noarch

How reproducible:
Everytime, see above and below.

Actual results:
SELinux forbids iptables(1) calls from OpenVPN client-(dis)connect scripts.

Expected results:
SELinux does not forbid iptables(1) calls from OpenVPN client-(dis)connect 
scripts.

Additional info:
# grep ^client- /etc/openvpn/road-server.conf 
client-connect /etc/openvpn/client-connect.sh
client-disconnect /etc/openvpn/client-disconnect.sh
#

# cat /etc/openvpn/client-connect.sh 
#!/bin/sh

IPT=`PATH=$PATH:/sbin:/usr/sbin/:/usr/local/sbin which iptables`

case "$common_name" in
"Tux")
  for i in VPN_TO_HOST VPN_TO_INT VPN_TO_VOIP VPN_TO_EXT; do
    $IPT -I $i -s $ifconfig_pool_remote_ip -p tcp --dport 0:65535 -j ACCEPT
    $IPT -I $i -s $ifconfig_pool_remote_ip -p udp --dport 0:65535 -j ACCEPT
  done
  exit 0
  ;;
# ...
esac

echo "No rules for $common_name"
exit 1
#

# cat /etc/openvpn/client-disconnect.sh 
#!/bin/sh

IPT=`PATH=$PATH:/sbin:/usr/sbin/:/usr/local/sbin which iptables`

case "$common_name" in
"Tux")
  for i in VPN_TO_HOST VPN_TO_INT VPN_TO_VOIP VPN_TO_EXT; do
    $IPT -D $i -s $ifconfig_pool_remote_ip -p tcp --dport 0:65535 -j ACCEPT
    $IPT -D $i -s $ifconfig_pool_remote_ip -p udp --dport 0:65535 -j ACCEPT
  done
  exit 0
  ;;
# ...
esac

echo "No rules for $common_name"
exit 1
#
Comment 1 Robert Scheck 2013-06-28 09:54:56 EDT
Cross-filed case #00897778 on the Red Hat customer portal.
Comment 3 Daniel Walsh 2013-06-28 14:24:15 EDT
Since these scripts could do anything, I think we need to make them unconfined, not just allow them to execute or runas iptables.
Comment 4 Miroslav Grepl 2013-07-01 06:33:34 EDT
What does

# rpm -qf /etc/openvpn/client-connect.sh
Comment 5 Robert Scheck 2013-07-01 07:24:51 EDT
(In reply to Daniel Walsh from comment #3)
> Since these scripts could do anything, I think we need to make them
> unconfined, not just allow them to execute or runas iptables.

Interesting thought, but I do not see how this will be solved as the script
can be named as the administrator wishes. There is no fixed name for these
scripts, it also could be /usr/local/bin/openvpn-something.sh...

# (In reply to Miroslav Grepl from comment #4)
> What does
> 
> # rpm -qf /etc/openvpn/client-connect.sh

# rpm -qf /etc/openvpn/client-connect.sh
file /etc/openvpn/client-connect.sh is not owned by any package
#

As said above, this will not help us. Alternatively we introduce a label and
expect some standard paths and the rest has to be labeled by admins, too? But
"man openvpn" also says that some could directly call iptables, if I am not
too mistaken by this?

--- snipp ---
[...]
--client-connect cmd

Run command cmd on client connection.

cmd consists of a path to script (or executable program), optionally followed 
by arguments. The path and arguments may be single- or double-quoted and/or 
escaped using a backslash, and should be separated by one or more spaces.

The command is passed the common name and IP address of the just-authenticated 
client as environmental variables (see environmental variable section below).  
The command is also passed the pathname of a freshly created temporary file as 
the last argument (after any arguments specified in cmd), to be used by the 
command to pass dynamically generated config file directives back to OpenVPN.

If the script wants to generate a dynamic config file to be applied on the 
server when the client connects, it should write it to the file named by the 
last argument.

See the --client-config-dir option below for options which can be legally used 
in a dynamically generated config file.

Note that the return value of script is significant. If script returns a non-
zero error status, it will cause the client to be disconnected.
[...]
--- snapp ---
Comment 6 Robert Scheck 2013-07-06 16:23:16 EDT
In order to get OpenVPN really working at the moment, this has to be added
e.g. via audit2allow, too:

type=AVC msg=audit(1373141198.664:715753): avc:  denied  { net_raw } for  pid=29284 comm="iptables" capability=13  scontext=unconfined_u:system_r:openvpn_t:s0 tcontext=unconfined_u:system_r:openvpn_t:s0 tclass=capability
type=SYSCALL msg=audit(1373141198.664:715753): arch=x86_64 syscall=socket success=no exit=EPERM a0=2 a1=3 a2=ff a3=4 items=0 ppid=29282 pid=29284 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=29397 comm=iptables exe=/sbin/iptables-multi-1.4.7 subj=unconfined_u:system_r:openvpn_t:s0 key=(null)

type=AVC msg=audit(1373141198.664:715754): avc:  denied  { execute } for  pid=29285 comm="iptables" name="modprobe" dev=sda2 ino=7340090 scontext=unconfined_u:system_r:openvpn_t:s0 tcontext=system_u:object_r:insmod_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1373141198.664:715754): arch=x86_64 syscall=execve success=no exit=EACCES a0=22f8390 a1=7ffface0c7e0 a2=7ffface0cba8 a3=400 items=0 ppid=29284 pid=29285 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=29397 comm=iptables exe=/sbin/iptables-multi-1.4.7 subj=unconfined_u:system_r:openvpn_t:s0 key=(null)

type=AVC msg=audit(1373141316.539:715814): avc:  denied  { getopt } for  pid=30083 comm="iptables" lport=255 scontext=unconfined_u:system_r:openvpn_t:s0 tcontext=unconfined_u:system_r:openvpn_t:s0 tclass=rawip_socket
type=SYSCALL msg=audit(1373141316.539:715814): arch=x86_64 syscall=getsockopt success=no exit=EACCES a0=3 a1=0 a2=40 a3=7fff4b9c59c0 items=0 ppid=30079 pid=30083 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=29397 comm=iptables exe=/sbin/iptables-multi-1.4.7 subj=unconfined_u:system_r:openvpn_t:s0 key=(null)

type=AVC msg=audit(1373141316.539:715815): avc:  denied  { read open } for  pid=30084 comm="iptables" name="modprobe" dev=sda2 ino=7340090 scontext=unconfined_u:system_r:openvpn_t:s0 tcontext=system_u:object_r:insmod_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1373141316.539:715815): arch=x86_64 syscall=execve success=no exit=EACCES a0=1f75390 a1=7fff4b9c5a00 a2=7fff4b9c5dc8 a3=400 items=0 ppid=30083 pid=30084 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=29397 comm=iptables exe=/sbin/iptables-multi-1.4.7 subj=unconfined_u:system_r:openvpn_t:s0 key=(null)

type=AVC msg=audit(1373141469.824:715893): avc:  denied  { setopt } for  pid=31021 comm="iptables" lport=255 scontext=unconfined_u:system_r:openvpn_t:s0 tcontext=unconfined_u:system_r:openvpn_t:s0 tclass=rawip_socket
type=SYSCALL msg=audit(1373141469.824:715893): arch=x86_64 syscall=setsockopt success=no exit=EACCES a0=3 a1=0 a2=40 a3=7f1dab3ad010 items=0 ppid=31019 pid=31021 auid=1005 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=38692 comm=iptables exe=/sbin/iptables-multi-1.4.7 subj=unconfined_u:system_r:openvpn_t:s0 key=(null)
Comment 7 Robert Scheck 2013-07-09 07:38:21 EDT
How are we going to proceed?
Comment 8 Daniel Walsh 2013-07-09 17:06:43 EDT
iptables_domtrans(openvpn_t)

Is probably better.  




We could ask openvpn to add an /etc/openvpn/scripts directory and change docs to talk about this directory.

194afdde0f7776e00b41989106e016217f66e88f adds this functionality to git.
Comment 9 Daniel Walsh 2013-07-09 17:07:23 EDT
Created attachment 771246 [details]
uncofined scripts support to openvpn
Comment 10 Miroslav Grepl 2013-08-06 02:39:30 EDT
I back ported SELinux fixes from Fedora.
Comment 13 errata-xmlrpc 2013-11-21 05:32:05 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.

http://rhn.redhat.com/errata/RHBA-2013-1598.html

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