openvpn and script execution

[Mr Dash Four]

I am trying to run openvpn within confined environment where the process 
runs under limited user/group (called _openvpn) and also using a 
specific SELinux context (allowed by openvpn itself when using the 
--setcon option). As part of this setup I also use the --iproute 
<ip-script>, --route-noexec and --route-up <route-up-script> options to 
provide the running of /sbin/ip and other such commands requiring 
privilege escalation (this is all done with sudo statements in those 
scripts).

The role of the <ip-script> is to set the options of the tun0 device on 
startup and then reset it when needed on ip address change or shutdown. 
There is a 'filter' implemented in this script, which prohibits adding 
or deleting routes (they are explicitly set with the route-up-script 
during startup and are not touched until the shutdown script is called 
when they are deleted and previous routes are then restored).

The role of the route-up-script is to set the routes, but just once (if 
called more than once it exits with status 0).

The role of the shutdown script is to reset the tun0 device, remove 
routes related to the openvpn and restore previous routes on the 
internal network. The startup and shutdown scripts which are executed by 
openvpn init.d script.

During startup and shutdown I am getting various AVCs, related, mainly 
to sudo, but also to openvpn itself. Here they are:

During openvpn startup (sudo-related):

type=AVC msg=audit(1284210049.555:96): avc:  denied  { getattr } for  
pid=2621 comm="<ip-script>" path="/usr/bin/sudo" dev=dm-0
ino=3226 
scontext=unconfined_u:system_r:openvpn_t:s0 
tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1284210049.555:96): arch=40000003 syscall=195 
success=yes exit=0 a0=8372838 a1=bfb19650 a2=b89ff4 a3=8372838 items=0 
ppid=2618 pid=2621 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 
sgid=0 fsgid=0 tty=(none) ses=1 comm="<ip-script>"
exe="/bin/bash" 
subj=unconfined_u:system_r:openvpn_t:s0 key=(null)
type=AVC msg=audit(1284210049.558:97): avc:  denied  { execute } for  
pid=2621 comm="<ip-script>" name="sudo" dev=dm-0 ino=3226 
scontext=unconfined_u:system_r:openvpn_t:s0 
tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1284210049.558:97): arch=40000003 syscall=33 
success=yes exit=0 a0=8372838 a1=1 a2=b89ff4 a3=8372838 items=0 
ppid=2618 pid=2621 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 
sgid=0 fsgid=0 tty=(none) ses=1 comm="<ip-script>"
exe="/bin/bash" 
subj=unconfined_u:system_r:openvpn_t:s0 key=(null)
type=AVC msg=audit(1284210049.559:98): avc:  denied  { read } for  
pid=2621 comm="<ip-script>" name="sudo" dev=dm-0 ino=3226 
scontext=unconfined_u:system_r:openvpn_t:s0 
tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1284210049.559:98): arch=40000003 syscall=33 
success=yes exit=0 a0=8372838 a1=4 a2=b89ff4 a3=8372838 items=0 
ppid=2618 pid=2621 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 
sgid=0 fsgid=0 tty=(none) ses=1 comm="<ip-script>"
exe="/bin/bash" 
subj=unconfined_u:system_r:openvpn_t:s0 key=(null)
type=AVC msg=audit(1284210049.564:99): avc:  denied  { open } for  
pid=2622 comm="<ip-script>" name="sudo" dev=dm-0 ino=3226 
scontext=unconfined_u:system_r:openvpn_t:s0 
tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file
type=AVC msg=audit(1284210049.564:99): avc:  denied  { execute_no_trans 
} for  pid=2622 comm="<ip-script>" path="/usr/bin/sudo" dev=dm-0

ino=3226 scontext=unconfined_u:system_r:openvpn_t:s0 
tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1284210049.564:99): arch=40000003 syscall=11 
success=yes exit=0 a0=8372838 a1=83716c0 a2=83713a8 a3=83716c0 items=0 
ppid=2621 pid=2622 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 
sgid=0 fsgid=0 tty=(none) ses=1 comm="sudo" exe="/usr/bin/sudo" 
subj=unconfined_u:system_r:openvpn_t:s0 key=(null)
type=AVC msg=audit(1284210049.590:100): avc:  denied  { sys_resource } 
for  pid=2622 comm="sudo" capability=24  
scontext=unconfined_u:system_r:openvpn_t:s0 
tcontext=unconfined_u:system_r:openvpn_t:s0 tclass=capability
type=AVC msg=audit(1284210049.590:100): avc:  denied  { setrlimit } for  
pid=2622 comm="sudo" scontext=unconfined_u:system_r:openvpn_t:s0 
tcontext=unconfined_u:system_r:openvpn_t:s0 tclass=process
type=SYSCALL msg=audit(1284210049.590:100): arch=40000003 syscall=75 
success=yes exit=0 a0=6 a1=bff9a1a8 a2=2afff4 a3=f01ce0 items=0 
ppid=2621 pid=2622 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 
sgid=0 fsgid=0 tty=(none) ses=1 comm="sudo" exe="/usr/bin/sudo" 
subj=unconfined_u:system_r:openvpn_t:s0 key=(null)
type=AVC msg=audit(1284210049.636:102): avc:  denied  { setsched } for  
pid=2622 comm="sudo" scontext=unconfined_u:system_r:openvpn_t:s0 
tcontext=unconfined_u:system_r:openvpn_t:s0 tclass=process
type=SYSCALL msg=audit(1284210049.636:102): arch=40000003 syscall=97 
success=yes exit=0 a0=0 a1=0 a2=0 a3=bff99b34 items=0 ppid=2621 pid=2622 
auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 
tty=(none) ses=1 comm="sudo" exe="/usr/bin/sudo" 
subj=unconfined_u:system_r:openvpn_t:s0 key=(null)

Also during openvpn startup, but related to openvpn itself (the possible 
cause of this is the --setcon openvpn option!):

type=AVC msg=audit(1284210049.853:110): avc:  denied  { setcurrent } 
for  pid=2618 comm="openvpn" scontext=unconfined_u:system_r:openvpn_t:s0 
tcontext=unconfined_u:system_r:openvpn_t:s0 tclass=process
type=AVC msg=audit(1284210049.853:110): avc:  denied  { dyntransition } 
for  pid=2618 comm="openvpn" scontext=unconfined_u:system_r:openvpn_t:s0 
tcontext=system_u:system_r:openvpn_t:s0 tclass=process
type=SYSCALL msg=audit(1284210049.853:110): arch=40000003 syscall=4 
success=yes exit=31 a0=6 a1=97125d0 a2=1f a3=97125d0 items=0 ppid=1 
pid=2618 auid=0 uid=498 gid=499 euid=498 suid=498 fsuid=498 egid=499 
sgid=499 fsgid=499 tty=(none) ses=1 comm="openvpn" 
exe="/usr/sbin/openvpn" subj=system_u:system_r:openvpn_t:s0 key=(null)


On openvpn shutdown, I get very similar sudo-related permissions as I 
did during startup:

type=AVC msg=audit(1284209679.447:83): avc:  denied  { getattr } for  
pid=2589 comm="<ip-script>" path="/usr/bin/sudo" dev=dm-0
ino=3226 
scontext=system_u:system_r:openvpn_t:s0 
tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1284209679.447:83): arch=40000003 syscall=195 
success=yes exit=0 a0=9509630 a1=bfadafa0 a2=491ff4 a3=9509630 items=0 
ppid=2532 pid=2589 auid=0 uid=498 gid=499 euid=498 suid=498 fsuid=498 
egid=499 sgid=499 fsgid=499 tty=(none) ses=1 comm="<ip-script>" 
exe="/bin/bash" subj=system_u:system_r:openvpn_t:s0 key=(null)
type=AVC msg=audit(1284209679.453:84): avc:  denied  { execute } for  
pid=2589 comm="<ip-script>" name="sudo" dev=dm-0 ino=3226 
scontext=system_u:system_r:openvpn_t:s0 
tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1284209679.453:84): arch=40000003 syscall=33 
success=yes exit=0 a0=9509630 a1=1 a2=491ff4 a3=9509630 items=0 
ppid=2532 pid=2589 auid=0 uid=498 gid=499 euid=498 suid=498 fsuid=498 
egid=499 sgid=499 fsgid=499 tty=(none) ses=1 comm="<ip-script>" 
exe="/bin/bash" subj=system_u:system_r:openvpn_t:s0 key=(null)
type=AVC msg=audit(1284209679.457:85): avc:  denied  { read open } for  
pid=2590 comm="<ip-script>" name="sudo" dev=dm-0 ino=3226 
scontext=system_u:system_r:openvpn_t:s0 
tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file
type=AVC msg=audit(1284209679.457:85): avc:  denied  { execute_no_trans 
} for  pid=2590 comm="<ip-script>" path="/usr/bin/sudo" dev=dm-0

ino=3226 scontext=system_u:system_r:openvpn_t:s0 
tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1284209679.457:85): arch=40000003 syscall=11 
success=yes exit=0 a0=9509630 a1=9508ae0 a2=9508888 a3=9508ae0 items=0 
ppid=2589 pid=2590 auid=0 uid=498 gid=499 euid=0 suid=0 fsuid=0 egid=499 
sgid=499 fsgid=499 tty=(none) ses=1 comm="sudo" exe="/usr/bin/sudo" 
subj=system_u:system_r:openvpn_t:s0 key=(null)
type=AVC msg=audit(1284209679.763:86): avc:  denied  { sys_resource } 
for  pid=2590 comm="sudo" capability=24  
scontext=system_u:system_r:openvpn_t:s0 
tcontext=system_u:system_r:openvpn_t:s0 tclass=capability
type=AVC msg=audit(1284209679.763:86): avc:  denied  { setrlimit } for  
pid=2590 comm="sudo" scontext=system_u:system_r:openvpn_t:s0 
tcontext=system_u:system_r:openvpn_t:s0 tclass=process
type=SYSCALL msg=audit(1284209679.763:86): arch=40000003 syscall=75 
success=yes exit=0 a0=6 a1=bf9cfb38 a2=6dbff4 a3=fc1ce0 items=0 
ppid=2589 pid=2590 auid=0 uid=498 gid=499 euid=0 suid=0 fsuid=0 egid=499 
sgid=499 fsgid=499 tty=(none) ses=1 comm="sudo" exe="/usr/bin/sudo" 
subj=system_u:system_r:openvpn_t:s0 key=(null)

The above AVCs were produced when I switched SELinux to permissive mode 
(setenforce 0) otherwise I wasn't able to run openvpn at all.

Is there any way I could get rid of those AVCs?

I am also not sure whether { setcurrent dyntransition } process 
permissions should be allowed in the openvpn.te as, as far as I can see, 
these are directly related to the use of the --setcon openvpn option.

[Dominick Grift]

On Sat, Sep 11, 2010 at 03:24:25PM +0100, Mr Dash Four wrote:
>  I am trying to run openvpn within confined environment where the
> process 
>  runs under limited user/group (called _openvpn) and also using a 
>  specific SELinux context (allowed by openvpn itself when using the 
>  --setcon option). As part of this setup I also use the --iproute 
>  <ip-script>, --route-noexec and --route-up <route-up-script> options to 
>  provide the running of /sbin/ip and other such commands requiring 
>  privilege escalation (this is all done with sudo statements in those 
>  scripts).
>  
>  The role of the <ip-script> is to set the options of the tun0 device on 
>  startup and then reset it when needed on ip address change or shutdown. 
>  There is a 'filter' implemented in this script, which prohibits adding 
>  or deleting routes (they are explicitly set with the route-up-script 
>  during startup and are not touched until the shutdown script is called 
>  when they are deleted and previous routes are then restored).
>  
>  The role of the route-up-script is to set the routes, but just once (if 
>  called more than once it exits with status 0).
>  
>  The role of the shutdown script is to reset the tun0 device, remove 
>  routes related to the openvpn and restore previous routes on the 
>  internal network. The startup and shutdown scripts which are executed by 
>  openvpn init.d script.
>  
>  During startup and shutdown I am getting various AVCs, related, mainly 
>  to sudo, but also to openvpn itself. Here they are:
>  
>  During openvpn startup (sudo-related):
>  
>  type=AVC msg=audit(1284210049.555:96): avc:  denied  { getattr } for  
>  pid=2621 comm="<ip-script>" path="/usr/bin/sudo" dev=dm-0
> ino=3226 
>  scontext=unconfined_u:system_r:openvpn_t:s0 
>  tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file
>  type=SYSCALL msg=audit(1284210049.555:96): arch=40000003 syscall=195 
>  success=yes exit=0 a0=8372838 a1=bfb19650 a2=b89ff4 a3=8372838 items=0 
>  ppid=2618 pid=2621 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 
>  sgid=0 fsgid=0 tty=(none) ses=1 comm="<ip-script>"
> exe="/bin/bash" 
>  subj=unconfined_u:system_r:openvpn_t:s0 key=(null)
>  type=AVC msg=audit(1284210049.558:97): avc:  denied  { execute } for  
>  pid=2621 comm="<ip-script>" name="sudo" dev=dm-0 ino=3226 
>  scontext=unconfined_u:system_r:openvpn_t:s0 
>  tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file
>  type=SYSCALL msg=audit(1284210049.558:97): arch=40000003 syscall=33 
>  success=yes exit=0 a0=8372838 a1=1 a2=b89ff4 a3=8372838 items=0 
>  ppid=2618 pid=2621 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 
>  sgid=0 fsgid=0 tty=(none) ses=1 comm="<ip-script>"
> exe="/bin/bash" 
>  subj=unconfined_u:system_r:openvpn_t:s0 key=(null)
>  type=AVC msg=audit(1284210049.559:98): avc:  denied  { read } for  
>  pid=2621 comm="<ip-script>" name="sudo" dev=dm-0 ino=3226 
>  scontext=unconfined_u:system_r:openvpn_t:s0 
>  tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file
>  type=SYSCALL msg=audit(1284210049.559:98): arch=40000003 syscall=33 
>  success=yes exit=0 a0=8372838 a1=4 a2=b89ff4 a3=8372838 items=0 
>  ppid=2618 pid=2621 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 
>  sgid=0 fsgid=0 tty=(none) ses=1 comm="<ip-script>"
> exe="/bin/bash" 
>  subj=unconfined_u:system_r:openvpn_t:s0 key=(null)
>  type=AVC msg=audit(1284210049.564:99): avc:  denied  { open } for  
>  pid=2622 comm="<ip-script>" name="sudo" dev=dm-0 ino=3226 
>  scontext=unconfined_u:system_r:openvpn_t:s0 
>  tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file
>  type=AVC msg=audit(1284210049.564:99): avc:  denied  { execute_no_trans 
>  } for  pid=2622 comm="<ip-script>" path="/usr/bin/sudo"
> dev=dm-0 
>  ino=3226 scontext=unconfined_u:system_r:openvpn_t:s0 
>  tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file
>  type=SYSCALL msg=audit(1284210049.564:99): arch=40000003 syscall=11 
>  success=yes exit=0 a0=8372838 a1=83716c0 a2=83713a8 a3=83716c0 items=0 
>  ppid=2621 pid=2622 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 
>  sgid=0 fsgid=0 tty=(none) ses=1 comm="sudo" exe="/usr/bin/sudo" 
>  subj=unconfined_u:system_r:openvpn_t:s0 key=(null)
>  type=AVC msg=audit(1284210049.590:100): avc:  denied  { sys_resource } 
>  for  pid=2622 comm="sudo" capability=24  
>  scontext=unconfined_u:system_r:openvpn_t:s0 
>  tcontext=unconfined_u:system_r:openvpn_t:s0 tclass=capability
>  type=AVC msg=audit(1284210049.590:100): avc:  denied  { setrlimit } for  
>  pid=2622 comm="sudo" scontext=unconfined_u:system_r:openvpn_t:s0 
>  tcontext=unconfined_u:system_r:openvpn_t:s0 tclass=process
>  type=SYSCALL msg=audit(1284210049.590:100): arch=40000003 syscall=75 
>  success=yes exit=0 a0=6 a1=bff9a1a8 a2=2afff4 a3=f01ce0 items=0 
>  ppid=2621 pid=2622 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 
>  sgid=0 fsgid=0 tty=(none) ses=1 comm="sudo" exe="/usr/bin/sudo" 
>  subj=unconfined_u:system_r:openvpn_t:s0 key=(null)
>  type=AVC msg=audit(1284210049.636:102): avc:  denied  { setsched } for  
>  pid=2622 comm="sudo" scontext=unconfined_u:system_r:openvpn_t:s0 
>  tcontext=unconfined_u:system_r:openvpn_t:s0 tclass=process
>  type=SYSCALL msg=audit(1284210049.636:102): arch=40000003 syscall=97 
>  success=yes exit=0 a0=0 a1=0 a2=0 a3=bff99b34 items=0 ppid=2621 pid=2622 
>  auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 
>  tty=(none) ses=1 comm="sudo" exe="/usr/bin/sudo" 
>  subj=unconfined_u:system_r:openvpn_t:s0 key=(null)
>  
>  Also during openvpn startup, but related to openvpn itself (the possible 
>  cause of this is the --setcon openvpn option!):
>  
>  type=AVC msg=audit(1284210049.853:110): avc:  denied  { setcurrent } 
>  for  pid=2618 comm="openvpn" scontext=unconfined_u:system_r:openvpn_t:s0 
>  tcontext=unconfined_u:system_r:openvpn_t:s0 tclass=process
>  type=AVC msg=audit(1284210049.853:110): avc:  denied  { dyntransition } 
>  for  pid=2618 comm="openvpn" scontext=unconfined_u:system_r:openvpn_t:s0 
>  tcontext=system_u:system_r:openvpn_t:s0 tclass=process
>  type=SYSCALL msg=audit(1284210049.853:110): arch=40000003 syscall=4 
>  success=yes exit=31 a0=6 a1=97125d0 a2=1f a3=97125d0 items=0 ppid=1 
>  pid=2618 auid=0 uid=498 gid=499 euid=498 suid=498 fsuid=498 egid=499 
>  sgid=499 fsgid=499 tty=(none) ses=1 comm="openvpn" 
>  exe="/usr/sbin/openvpn" subj=system_u:system_r:openvpn_t:s0 key=(null)
>  
>  
>  On openvpn shutdown, I get very similar sudo-related permissions as I 
>  did during startup:
>  
>  type=AVC msg=audit(1284209679.447:83): avc:  denied  { getattr } for  
>  pid=2589 comm="<ip-script>" path="/usr/bin/sudo" dev=dm-0
> ino=3226 
>  scontext=system_u:system_r:openvpn_t:s0 
>  tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file
>  type=SYSCALL msg=audit(1284209679.447:83): arch=40000003 syscall=195 
>  success=yes exit=0 a0=9509630 a1=bfadafa0 a2=491ff4 a3=9509630 items=0 
>  ppid=2532 pid=2589 auid=0 uid=498 gid=499 euid=498 suid=498 fsuid=498 
>  egid=499 sgid=499 fsgid=499 tty=(none) ses=1 comm="<ip-script>" 
>  exe="/bin/bash" subj=system_u:system_r:openvpn_t:s0 key=(null)
>  type=AVC msg=audit(1284209679.453:84): avc:  denied  { execute } for  
>  pid=2589 comm="<ip-script>" name="sudo" dev=dm-0 ino=3226 
>  scontext=system_u:system_r:openvpn_t:s0 
>  tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file
>  type=SYSCALL msg=audit(1284209679.453:84): arch=40000003 syscall=33 
>  success=yes exit=0 a0=9509630 a1=1 a2=491ff4 a3=9509630 items=0 
>  ppid=2532 pid=2589 auid=0 uid=498 gid=499 euid=498 suid=498 fsuid=498 
>  egid=499 sgid=499 fsgid=499 tty=(none) ses=1 comm="<ip-script>" 
>  exe="/bin/bash" subj=system_u:system_r:openvpn_t:s0 key=(null)
>  type=AVC msg=audit(1284209679.457:85): avc:  denied  { read open } for  
>  pid=2590 comm="<ip-script>" name="sudo" dev=dm-0 ino=3226 
>  scontext=system_u:system_r:openvpn_t:s0 
>  tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file
>  type=AVC msg=audit(1284209679.457:85): avc:  denied  { execute_no_trans 
>  } for  pid=2590 comm="<ip-script>" path="/usr/bin/sudo"
> dev=dm-0 
>  ino=3226 scontext=system_u:system_r:openvpn_t:s0 
>  tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file
>  type=SYSCALL msg=audit(1284209679.457:85): arch=40000003 syscall=11 
>  success=yes exit=0 a0=9509630 a1=9508ae0 a2=9508888 a3=9508ae0 items=0 
>  ppid=2589 pid=2590 auid=0 uid=498 gid=499 euid=0 suid=0 fsuid=0 egid=499 
>  sgid=499 fsgid=499 tty=(none) ses=1 comm="sudo" exe="/usr/bin/sudo" 
>  subj=system_u:system_r:openvpn_t:s0 key=(null)
>  type=AVC msg=audit(1284209679.763:86): avc:  denied  { sys_resource } 
>  for  pid=2590 comm="sudo" capability=24  
>  scontext=system_u:system_r:openvpn_t:s0 
>  tcontext=system_u:system_r:openvpn_t:s0 tclass=capability
>  type=AVC msg=audit(1284209679.763:86): avc:  denied  { setrlimit } for  
>  pid=2590 comm="sudo" scontext=system_u:system_r:openvpn_t:s0 
>  tcontext=system_u:system_r:openvpn_t:s0 tclass=process
>  type=SYSCALL msg=audit(1284209679.763:86): arch=40000003 syscall=75 
>  success=yes exit=0 a0=6 a1=bf9cfb38 a2=6dbff4 a3=fc1ce0 items=0 
>  ppid=2589 pid=2590 auid=0 uid=498 gid=499 euid=0 suid=0 fsuid=0 egid=499 
>  sgid=499 fsgid=499 tty=(none) ses=1 comm="sudo" exe="/usr/bin/sudo" 
>  subj=system_u:system_r:openvpn_t:s0 key=(null)
>  
>  The above AVCs were produced when I switched SELinux to permissive mode 
>  (setenforce 0) otherwise I wasn't able to run openvpn at all.
>  
>  Is there any way I could get rid of those AVCs?
>  
>  I am also not sure whether { setcurrent dyntransition } process 
>  permissions should be allowed in the openvpn.te as, as far as I can see, 
>  these are directly related to the use of the --setcon openvpn option. 
I guess current policy does not support the openvpn --setcon option. Also i am not sure
what context you specified with --setcon but it looks like you specified the same context
as openvpn was running in. You could implement this functionality i guess though. You
would have to create some domains for openvpn to transition to.

I am not sure why you are using sudo. If the rc script runs the scripts then the scripts
probably run as root.

I would probably try this another way, without having to dyntransition. I am not sure what
runs the scripts other then the open vpn rc script. But you could probably simply create
domains for each script and let the rc script domain transiton to each scripts domain, The
you could probably also do some nice things with role based access control.

What scripts are there and who/what runs each of them? Why are the running sudo, what
makes you think they need it?

>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Mr Dash Four]

>  I guess current policy does not support the openvpn --setcon option.
> Also i am not sure what context you specified with --setcon but it looks like you
> specified the same context as openvpn was running in. 
It is slightly different - as
I am starting it from the command line 
(manually) it initially runs in unonfined_u::system_r:openvpn_t, then 
changes to system_u::system_r:openvpn_t

>   You could implement this functionality i guess though. You would
> have to create some domains for openvpn to transition to.
>     
How do I do that?

>  I am not sure why you are using sudo. If the rc script runs the
> scripts then the scripts probably run as root.
>     
Nope! That is the long-standing issue I have been having with openvpn - 
it runs as an unprivileged user (_openvpn:_openvpn). As such, commands 
altering the route table and the like are NOT permitted (even if they 
execute, they fail to do what they are supposed to - exiting usually 
with error status 2 or 13).

>  I would probably try this another way, without having to
> dyntransition. 
I've spend some time studying the sudo.te file, but still
can't figure 
it out.

>   I am not sure what runs the scripts other then the open vpn rc
> script. 
openvpn (the executable) runs the <ip-script> and
<route-up-script> (see 
below), while /etc/init.d/openvpn runs the openvpn-startup and 
openvpn-stop scripts (again, see below).

>   But you could probably simply create domains for each script and let
> the rc script domain transiton to each scripts domain, The you could probably also do some
> nice things with role based access control.
>     
How? Please elaborate!
>  What scripts are there and who/what runs each of them? Why are the
> running sudo, what makes you think they need it?
>     
Here they are (simplified version):

====openvpn-startup-script (executes only once at startup and is called 
from /etc/init.d/openvpn directly)===
#!/bin/sh

openvpn --mktun --dev tun0 --user _openvpn --group _openvpn
=============

====ip-script===
#!/bin/sh

if [ "$1" != route ]; then
  echo openvpn ip called
  sudo /sbin/ip $1 $2 $3 $4 $5 $6 $7 $8 $9
fi
=============

Sudo makes sure that adding/deleting of routes is not allowed (this is 
also supposed to be prevented with the route-noexec option, but it does 
not always work).

====route-up-script===
#!/bin/sh

ROUTE_UP=/var/lib/openvpn/.route-up-started
if ! [ -f  $ROUTE_UP ]
then
  echo openvpn route-up called
  /sbin/ip route add <remote_vpn_host_ip> via <local_gateway_ip>
  /sbin/ip route add 0.0.0.0/1 via <tun0_end_point>
  /sbin/ip route add 128.0.0.0/1 via <tun0_end_point>
  /sbin/ip route add <dmz_net> via <local_gateway_ip>
  /sbin/ip route add <green_net> via <local_gateway_ip>
  touch $ROUTE_UP
fi
=============

====openvpn-stop-script (executes only once at shutdown and is called 
from /etc/init.d/openvpn directly)===
#!/bin/sh

ROUTE_UP=/var/lib/openvpn/.route-up-started
#/sbin/ifconfig tun0 down
echo openvpn shutdown called
sudo /sbin/route del <remote_vpn_host_ip>
sudo /sbin/ip route add <default on eth0/eth1> via <local_gateway_ip>
rm $ROUTE_UP
=============

I need to mention that /var/lib/openvpn and all its files have the 
appropriate labelling - system_u:object_r:openvpn_etc_t:s0 set.

The openvpn-startup and route-up scripts are the only ones running with 
root privileges, all other scripts are run within confined environment 
(with _openvpn:_openvpn set), hence why sudo is needed - /sbin/ip even 
though it may be executed, it cannot alter/change the routing table, 
add/del tun or other net devices etc if it runs in confined environment 
- that is the issue I have been having with openvpn for quite a while 
and is the main reason why designed the scripts (also to control and 
filter down various other openvpn stupidities!) and reverted to using sudo.

[Dominick Grift]

On Sat, Sep 11, 2010 at 04:34:15PM +0100, Mr Dash Four wrote:

I think i am starting to understand the issues now:

The setcon option is the selinux equivalent of the user option:
- The user option drops tradional linux priveleges by going from root to an unprivilged
user
- The setcon option drops selinux privileges by going for the default openvpn selinux
domain to a specified domain (usually with less privileges)

To drop selinux privileges, you need to create a selinux domain with less privileges then
the original openvpn domain, and allow the original openvpn domain to dyntransition to
this new selinux domain with less privileges.
The question here is: Which selinux privileges can be dropped?

Your other issue is your scripts. Currently it seems that these scripts probably run in
the openvpn domain. Thus with the openvpn user privileges and the openvpn selinux
privileges.
From an selinux point of view that means your scripts can leak to openvpn and vice versa.

You could create selinux domains for each script and extend openvpn policy to allow
openvpn to transition to each scripts selinux domain, when openvpn runs the script.

That leaves us with the sudo issue. This is only an issue for scripts run as non-root (so
for scripts run from the openvpn rc script this is no issue)

That means that the selinux domain for the scripts that do not run as root need to be
allowed to run sudo i guess (i still think thats a bad idea but so be it)

So all-in-all a lot of work to do:

1. create a openvpn selinux domain for openvpn to drop to:
- which selinux permissions can be dropped?
2. create selinux domains for each of your scripts and allow openvpn or init to domain
transition to them.
- allow the scripts started by openvpn to run sudo to gain privileges.

The question is: can all this work be justified?

I can help you implement it but i warn you that it will require much testing and i am not
sure if it will benefit security that signicantly.


>  
>  >I guess current policy does not support the openvpn --setcon option. Also i am not
> sure what context you specified with --setcon but it looks like you specified the same
> context as openvpn was running in.
>  It is slightly different - as I am starting it from the command line
>  (manually) it initially runs in unonfined_u::system_r:openvpn_t,
>  then changes to system_u::system_r:openvpn_t
>  
>  > You could implement this functionality i guess though. You would have to create some
> domains for openvpn to transition to.
>  How do I do that?
>  
>  >I am not sure why you are using sudo. If the rc script runs the scripts then the
> scripts probably run as root.
>  Nope! That is the long-standing issue I have been having with
>  openvpn - it runs as an unprivileged user (_openvpn:_openvpn). As
>  such, commands altering the route table and the like are NOT
>  permitted (even if they execute, they fail to do what they are
>  supposed to - exiting usually with error status 2 or 13).
>  
>  >I would probably try this another way, without having to dyntransition.
>  I've spend some time studying the sudo.te file, but still can't
>  figure it out.
>  
>  > I am not sure what runs the scripts other then the open vpn rc script.
>  openvpn (the executable) runs the <ip-script> and <route-up-script>
>  (see below), while /etc/init.d/openvpn runs the openvpn-startup and
>  openvpn-stop scripts (again, see below).
>  
>  > But you could probably simply create domains for each script and let the rc script
> domain transiton to each scripts domain, The you could probably also do some nice things
> with role based access control.
>  How? Please elaborate!
>  >What scripts are there and who/what runs each of them? Why are the running sudo, what
> makes you think they need it?
>  
>  Here they are (simplified version):
>  
>  ====openvpn-startup-script (executes only once at startup and is
>  called from /etc/init.d/openvpn directly)===
>  #!/bin/sh
>  
>  openvpn --mktun --dev tun0 --user _openvpn --group _openvpn
>  =============
>  
>  ====ip-script===
>  #!/bin/sh
>  
>  if [ "$1" != route ]; then
>   echo openvpn ip called
>   sudo /sbin/ip $1 $2 $3 $4 $5 $6 $7 $8 $9
>  fi
>  =============
>  
>  Sudo makes sure that adding/deleting of routes is not allowed (this
>  is also supposed to be prevented with the route-noexec option, but
>  it does not always work).
>  
>  ====route-up-script===
>  #!/bin/sh
>  
>  ROUTE_UP=/var/lib/openvpn/.route-up-started
>  if ! [ -f  $ROUTE_UP ]
>  then
>   echo openvpn route-up called
>   /sbin/ip route add <remote_vpn_host_ip> via <local_gateway_ip>
>   /sbin/ip route add 0.0.0.0/1 via <tun0_end_point>
>   /sbin/ip route add 128.0.0.0/1 via <tun0_end_point>
>   /sbin/ip route add <dmz_net> via <local_gateway_ip>
>   /sbin/ip route add <green_net> via <local_gateway_ip>
>   touch $ROUTE_UP
>  fi
>  =============
>  
>  ====openvpn-stop-script (executes only once at shutdown and is
>  called from /etc/init.d/openvpn directly)===
>  #!/bin/sh
>  
>  ROUTE_UP=/var/lib/openvpn/.route-up-started
>  #/sbin/ifconfig tun0 down
>  echo openvpn shutdown called
>  sudo /sbin/route del <remote_vpn_host_ip>
>  sudo /sbin/ip route add <default on eth0/eth1> via <local_gateway_ip>
>  rm $ROUTE_UP
>  =============
>  
>  I need to mention that /var/lib/openvpn and all its files have the
>  appropriate labelling - system_u:object_r:openvpn_etc_t:s0 set.
>  
>  The openvpn-startup and route-up scripts are the only ones running
>  with root privileges, all other scripts are run within confined
>  environment (with _openvpn:_openvpn set), hence why sudo is needed -
>  /sbin/ip even though it may be executed, it cannot alter/change the
>  routing table, add/del tun or other net devices etc if it runs in
>  confined environment - that is the issue I have been having with
>  openvpn for quite a while and is the main reason why designed the
>  scripts (also to control and filter down various other openvpn
>  stupidities!) and reverted to using sudo.
>

[Mr Dash Four]

>  To drop selinux privileges, you need to create a selinux domain with
> less privileges then the original openvpn domain, and allow the original openvpn domain to
> dyntransition to this new selinux domain with less privileges.
>  The question here is: Which selinux privileges can be dropped?
>     
The domain I am trying to get to is not different from the one openvpn 
is running on - the difference is the user (unconfined_u as oppose to 
system_u) - the rest is exactly the same - openvpn_t. So, in short - the 
transition is from unconfined_t:system_r:openvpn_t -> 
system_u:system_r:openvpn_t. I don't know SELinux enough to judge 
whether that is a big 'drop' or if it presents a major risk if I run it 
in "unconfined_u:system_r:openvpn_t", but if it doesn't that I may drop 
the --selcon option and leave openvpn to run in 
unconfined_t:system_r:openvpn_t.

>  Your other issue is your scripts. Currently it seems that these
> scripts probably run in the openvpn domain. Thus with the openvpn user privileges and the
> openvpn selinux privileges.
>     
That is correct!

>  From an selinux point of view that means your scripts can leak to
> openvpn and vice versa.
>     
The alternative is to leave openvpn to run as root (and be able to 
execute the scripts as root without further difficulties), but I am not 
sure that is a good idea! Leaving openvpn to execute /sbin/ip directly 
is out of the question!

>  You could create selinux domains for each script and extend openvpn
> policy to allow openvpn to transition to each scripts selinux domain, when openvpn runs
> the script.
>     
Is that done with init_daemon_domain()?

>  That leaves us with the sudo issue. This is only an issue for scripts
> run as non-root (so for scripts run from the openvpn rc script this is no issue)
>
>  That means that the selinux domain for the scripts that do not run as root need to be
> allowed to run sudo i guess (i still think thats a bad idea but so be it)
>
>  So all-in-all a lot of work to do:
>
>  1. create a openvpn selinux domain for openvpn to drop to:
>  - which selinux permissions can be dropped?
>  2. create selinux domains for each of your scripts and allow openvpn or init to domain
> transition to them.
>  - allow the scripts started by openvpn to run sudo to gain privileges.
>
>  The question is: can all this work be justified?
>     
How much work would that be - I am no SELinux expert, but thought that 
apart from the dyntransition and the other openvpn-related AVC (which 
will be gone if I do not use the --selcon option) the rest are simple 
exec file privileges, which if granted, then will make the whole issue 
go away. I might be wrong though.

There is one other thing though - openvpn_t is trying to execute 
sudo_exec_t. I wonder if sudo_exec_t does have these privileges and I 
just need to transition to this domain (if at all)?

>  I can help you implement it but i warn you that it will require much
> testing and i am not sure if it will benefit security that signicantly.
>     
I am not afraid of testing, though I am not convinced that running 
openvpn as root (even in the openvpn_t domain) is a good idea either!

As far as sudo goes - if there are alternative ways which give me proper 
security and allow me to execute /sbin/ip safely, I will gladly accept 
those - no question!

[Dominick Grift]

On Sat, Sep 11, 2010 at 06:01:02PM +0100, Mr Dash Four wrote:
>  
>  >To drop selinux privileges, you need to create a selinux domain with less privileges
> then the original openvpn domain, and allow the original openvpn domain to dyntransition
> to this new selinux domain with less privileges.
>  >The question here is: Which selinux privileges can be dropped?
>  The domain I am trying to get to is not different from the one
>  openvpn is running on - the difference is the user (unconfined_u as
>  oppose to system_u) - the rest is exactly the same - openvpn_t. So,
>  in short - the transition is from unconfined_t:system_r:openvpn_t ->
>  system_u:system_r:openvpn_t. I don't know SELinux enough to judge
>  whether that is a big 'drop' or if it presents a major risk if I run
>  it in "unconfined_u:system_r:openvpn_t", but if it doesn't that I
>  may drop the --selcon option and leave openvpn to run in
>  unconfined_t:system_r:openvpn_t. 
Its not significant the _u field does not enforce any restrictions in Fedora.
So if that is your reason to use -setcon you can can skip it.

>  
>  >Your other issue is your scripts. Currently it seems that these scripts probably run
> in the openvpn domain. Thus with the openvpn user privileges and the openvpn selinux
> privileges.
>  That is correct!
>  
>  >From an selinux point of view that means your scripts can leak to openvpn and vice
> versa.
>  The alternative is to leave openvpn to run as root (and be able to
>  execute the scripts as root without further difficulties), but I am
>  not sure that is a good idea! Leaving openvpn to execute /sbin/ip
>  directly is out of the question!
>  
>  >You could create selinux domains for each script and extend openvpn policy to allow
> openvpn to transition to each scripts selinux domain, when openvpn runs the script.
>  Is that done with init_daemon_domain()?
>  
>  >That leaves us with the sudo issue. This is only an issue for scripts run as non-root
> (so for scripts run from the openvpn rc script this is no issue)
>  >
>  >That means that the selinux domain for the scripts that do not run as root need to be
> allowed to run sudo i guess (i still think thats a bad idea but so be it)
>  >
>  >So all-in-all a lot of work to do:
>  >
>  >1. create a openvpn selinux domain for openvpn to drop to:
>  >- which selinux permissions can be dropped?
>  >2. create selinux domains for each of your scripts and allow openvpn or init to
> domain transition to them.
>  >- allow the scripts started by openvpn to run sudo to gain privileges.
>  >
>  >The question is: can all this work be justified?
>  How much work would that be - I am no SELinux expert, but thought
>  that apart from the dyntransition and the other openvpn-related AVC
>  (which will be gone if I do not use the --selcon option) the rest
>  are simple exec file privileges, which if granted, then will make
>  the whole issue go away. I might be wrong though. 
The dyntransition no longer applies since you wanted to use it to change the selinux user
field which is insignifcant.

>  There is one other thing though - openvpn_t is trying to execute
>  sudo_exec_t. I wonder if sudo_exec_t does have these privileges and
>  I just need to transition to this domain (if at all)? 
The issue that openvpn_t needs access is a problem. Because if openvpn_t can run sudo it
can run commands as root.

Therefore we must make sure its not openvpn_t that runs sudo but the scripts domains.
if we define domains for the script to be run in, then it is the script domain that needs
access to sudo and not openvpn_t domain.

>  
>  >I can help you implement it but i warn you that it will require much testing and i am
> not sure if it will benefit security that signicantly.
>  I am not afraid of testing, though I am not convinced that running
>  openvpn as root (even in the openvpn_t domain) is a good idea
>  either! 
Question is does security risk justify the work that needs to be done.

Basically you say i want openvpn to drop privileges and once it dropped privileges you
later need it to gain privileges again to run the scripts.

>  
>  As far as sudo goes - if there are alternative ways which give me
>  proper security and allow me to execute /sbin/ip safely, I will
>  gladly accept those - no question! 
Where are the scripts located? (make sure they are in the location where they will be in
the future.

[Mr Dash Four]

>  Its not significant the _u field does not enforce any restrictions in
> Fedora.
>  So if that is your reason to use -setcon you can can skip it.
>     
OK, 2 AVC will be gone then.

> > There is one other thing though - openvpn_t is trying to execute
> > sudo_exec_t. I wonder if sudo_exec_t does have these privileges and
> > I just need to transition to this domain (if at all)?
> >     
>
>  The issue that openvpn_t needs access is a problem. Because if openvpn_t can run sudo it
> can run commands as root.
>
>  Therefore we must make sure its not openvpn_t that runs sudo but the scripts domains.
>  if we define domains for the script to be run in, then it is the script domain that needs
> access to sudo and not openvpn_t domain.
>     
2 questions - is it possible to drop/use sudo_exec_t and if so does this 
domain have the necessary privileges to run what I want - I am not sure. 
Having looked at sudo.te I can't make much sense.

> > I am not afraid of testing, though I am not convinced that
> running
> > openvpn as root (even in the openvpn_t domain) is a good idea
> > either!
> >     
>
>  Question is does security risk justify the work that needs to be done.
>     
Well, the alternative, as I pointed out, is to leave openvpn running as 
root under openvpn_t. Do you think that's better?

>  Basically you say i want openvpn to drop privileges and once it
> dropped privileges you later need it to gain privileges again to run the scripts.
>     
That's because whoever wrote the code for openvpn was a short-sighted 
idiot!!!

For openvpn to run properly it needs to execute external programs (like 
/sbin/ip) in order to alter the routing table and to also modify various 
ethernet devices on the host system - a set of privileges which Linux, 
as an OS, can only grant to root and nobody else.

So there are two possible ways of running openvpn: 1) run it with root 
privileges and avoid all the headaches I described in my last couple of 
posts, though running the risk that some clever head out there might use 
openvpn vulnerabilities to take control over your machine as it would be 
much easier to do that when openvpn is ran as root; or 2) drop openvpn 
privileges and escalate them only when necessary to run the scripts 
which execute /sbin/ip to alter the above parameters.

Out of the above 2 ways I know which one's safer! If there is a 3rd way 
I would be glad to hear it.

> > As far as sudo goes - if there are alternative ways which give
> me
> > proper security and allow me to execute /sbin/ip safely, I will
> > gladly accept those - no question!
> >     
>
>  Where are the scripts located? (make sure they are in the location where they will be in
> the future.
>     
All of them a located in /var/lib/openvpn - this directory and all its 
files have system_u:object_r:openvpn_etc_t:s0 SELinux context (owner is 
root, group is _openvpn).

[Dominick Grift]

On Sat, Sep 11, 2010 at 06:28:42PM +0100, Mr Dash Four wrote:
>  
>  >Its not significant the _u field does not enforce any restrictions in Fedora.
>  >So if that is your reason to use -setcon you can can skip it.
>  OK, 2 AVC will be gone then.
>  
>  >>There is one other thing though - openvpn_t is trying to execute
>  >>sudo_exec_t. I wonder if sudo_exec_t does have these privileges and
>  >>I just need to transition to this domain (if at all)?
>  >
>  >The issue that openvpn_t needs access is a problem. Because if openvpn_t can run sudo
> it can run commands as root.
>  >
>  >Therefore we must make sure its not openvpn_t that runs sudo but the scripts
> domains.
>  >if we define domains for the script to be run in, then it is the script domain that
> needs access to sudo and not openvpn_t domain.
>  2 questions - is it possible to drop/use sudo_exec_t and if so does
>  this domain have the necessary privileges to run what I want - I am
>  not sure. Having looked at sudo.te I can't make much sense. 
The sudo policy currently only supports that sudo is run by users, not by scripts.
But we could hack around that, we could run sudo in the callers domain, but that would
mean that the caller domain needs the privileges to run sudo.
>  
>  >>I am not afraid of testing, though I am not convinced that running
>  >>openvpn as root (even in the openvpn_t domain) is a good idea
>  >>either!
>  >
>  >Question is does security risk justify the work that needs to be done.
>  Well, the alternative, as I pointed out, is to leave openvpn running
>  as root under openvpn_t. Do you think that's better? 
I think in your scenario it may not make that much of a difference. Your scenario being
that you have openvpn run scripts that need root.
You have selinux to confine root (openvpn)
if you use an unprivileged user you need to either allow openvpn to run sudo which
basically pretty much negates the dropping root measure.

or you have to confine your scripts so that from an selinux perspective its no longer
openvpn that needs to run sudo but its your script domains.

The benefit of that would be that your scripts cannot mess with openvpn and its files.

The downside is that you need to write/maintain a few custom modules.

Being that you are not so familair with selinux and that its hard for me to guide you by
using e-mail, it might be tempting to just run openvpn as root. Its protected by selinux
so its not that bad.

>  
>  >Basically you say i want openvpn to drop privileges and once it dropped privileges
> you later need it to gain privileges again to run the scripts.
>  That's because whoever wrote the code for openvpn was a
>  short-sighted idiot!!! 
Well i doubt it, remember that those are options, just as running scripts from openvpn is
a option.

>  
>  For openvpn to run properly it needs to execute external programs
>  (like /sbin/ip) in order to alter the routing table and to also
>  modify various ethernet devices on the host system - a set of
>  privileges which Linux, as an OS, can only grant to root and nobody
>  else.
>  
>  So there are two possible ways of running openvpn: 1) run it with
>  root privileges and avoid all the headaches I described in my last
>  couple of posts, though running the risk that some clever head out
>  there might use openvpn vulnerabilities to take control over your
>  machine as it would be much easier to do that when openvpn is ran as
>  root; 
Just because someone gains root through openvpn does not mean that he automatically has
control over your system.
That where selinux comes in. Even though the attacker is root, the attacker is still
confined to the openvpn_t selinux domain.

Basically the attacker is stuck with just the open vpn privileges. So he could mess with
open vpn and some other stuff but not the whole system.

 or 2) drop openvpn privileges and escalate them only when
>  necessary to run the scripts which execute /sbin/ip to alter the
>  above parameters. 
possible but relatively much work, especially if youre not familair with selinux.
also be benefit is not that great imho.

>  
>  Out of the above 2 ways I know which one's safer! If there is a 3rd
>  way I would be glad to hear it. 

I think thats basically it.
>  
>  >>As far as sudo goes - if there are alternative ways which give me
>  >>proper security and allow me to execute /sbin/ip safely, I will
>  >>gladly accept those - no question!
>  >
>  >Where are the scripts located? (make sure they are in the location where they will be
> in the future.
>  All of them a located in /var/lib/openvpn - this directory and all
>  its files have system_u:object_r:openvpn_etc_t:s0 SELinux context
>  (owner is root, group is _openvpn). 
openvpn does not install /var/lib/openvpn. plus the type openvpn_etc_t is not suitable for
stateful data (open vpn can read it but not write it)

[Mr Dash Four]

>  The sudo policy currently only supports that sudo is run by users,
> not by scripts.
>  But we could hack around that, we could run sudo in the callers domain, but that would
> mean that the caller domain needs the privileges to run sudo.
>     
There is a macro in sudo.if called sudo_role_template which appears to 
do a similar thing. Again, my selinux knowledge is not that great to 
judge if it is of any use in my case.

>  I think in your scenario it may not make that much of a difference.
> Your scenario being that you have openvpn run scripts that need root.
>  You have selinux to confine root (openvpn)
>  if you use an unprivileged user you need to either allow openvpn to run sudo which
> basically pretty much negates the dropping root measure.
>     
Well, no, because sudo is run from my scripts (not directly by openvpn) 
and escalating of privileges happens only during that time - while sudo 
executes a specific command (/sbin/ip in this case) in that specific 
script. For the rest of the time openvpn runs in openvpn_t AND the user 
is not root. Much safer!

>  or you have to confine your scripts so that from an selinux
> perspective its no longer openvpn that needs to run sudo but its your script domains.
>
>  The benefit of that would be that your scripts cannot mess with openvpn and its files.
>
>  The downside is that you need to write/maintain a few custom modules.
>
>  Being that you are not so familair with selinux and that its hard for me to guide you by
> using e-mail, it might be tempting to just run openvpn as root. Its protected by selinux
> so its not that bad.
>     
I will look for an alternatives then as running openvpn as root does not 
sit well with me at all - just not going to happen.

>  Well i doubt it, remember that those are options, just as running
> scripts from openvpn is a option.
>     
Bad design - that is what I was trying to point out. You cannot run 
openvpn as non-root as it needs to be (at least at some point) root in 
order to function properly. As I said - a lousy job!

>  Just because someone gains root through openvpn does not mean that he
> automatically has control over your system.
>  That where selinux comes in. Even though the attacker is root, the attacker is still
> confined to the openvpn_t selinux domain.
>
>  Basically the attacker is stuck with just the open vpn privileges. So he could mess with
> open vpn and some other stuff but not the whole system.
>     
I understand that, but it presents a loophole which could be exploited - 
I do not like that one single bit.

>  openvpn does not install /var/lib/openvpn. plus the type
> openvpn_etc_t is not suitable for stateful data (open vpn can read it but not write it)
>     
Actually, it can - see the "touch $ROUTE_UP" statement in one of the 
scripts - it executes successfully in that directory - no problem.

[Dominick Grift]

On Sat, Sep 11, 2010 at 07:11:01PM +0100, Mr Dash Four wrote:
>  
>  >The sudo policy currently only supports that sudo is run by users, not by scripts.
>  >But we could hack around that, we could run sudo in the callers domain, but that
> would mean that the caller domain needs the privileges to run sudo.
>  There is a macro in sudo.if called sudo_role_template which appears
>  to do a similar thing. Again, my selinux knowledge is not that great
>  to judge if it is of any use in my case. 
Role templates are to be called by users, not by scripts or other agents.

>  
>  >I think in your scenario it may not make that much of a difference. Your scenario
> being that you have openvpn run scripts that need root.
>  >You have selinux to confine root (openvpn)
>  >if you use an unprivileged user you need to either allow openvpn to run sudo which
> basically pretty much negates the dropping root measure.
>  Well, no, because sudo is run from my scripts (not directly by
>  openvpn) and escalating of privileges happens only during that time
>  - while sudo executes a specific command (/sbin/ip in this case) in
>  that specific script. For the rest of the time openvpn runs in
>  openvpn_t AND the user is not root. Much safer! 
From a selinux perspective it is run by openvpn unless openvpn_t domain transitions to
another domain.
>  
>  >or you have to confine your scripts so that from an selinux perspective its no longer
> openvpn that needs to run sudo but its your script domains.
>  >
>  >The benefit of that would be that your scripts cannot mess with openvpn and its
> files.
>  >
>  >The downside is that you need to write/maintain a few custom modules.
>  >
>  >Being that you are not so familair with selinux and that its hard for me to guide you
> by using e-mail, it might be tempting to just run openvpn as root. Its protected by
> selinux so its not that bad.
>  I will look for an alternatives then as running openvpn as root does
>  not sit well with me at all - just not going to happen. 
A possbile slution would be to create domains for your scripts and alloww openvpn to
domain transition to th script domain when it run the scripts.
That way openvpn domain does not need access to run sudo but instead the script domains
need it.

>  
>  >Well i doubt it, remember that those are options, just as running scripts from
> openvpn is a option.
>  Bad design - that is what I was trying to point out. You cannot run
>  openvpn as non-root as it needs to be (at least at some point) root
>  in order to function properly. As I said - a lousy job!
>  
>  >Just because someone gains root through openvpn does not mean that he automatically
> has control over your system.
>  >That where selinux comes in. Even though the attacker is root, the attacker is still
> confined to the openvpn_t selinux domain.
>  >
>  >Basically the attacker is stuck with just the open vpn privileges. So he could mess
> with open vpn and some other stuff but not the whole system.
>  I understand that, but it presents a loophole which could be
>  exploited - I do not like that one single bit.
>  
>  >openvpn does not install /var/lib/openvpn. plus the type openvpn_etc_t is not
> suitable for stateful data (open vpn can read it but not write it)
>  Actually, it can - see the "touch $ROUTE_UP" statement in one of the
>  scripts - it executes successfully in that directory - no problem. 
Are you sure its not one of the script run by init instead?

[Mr Dash Four]

>  A possbile slution would be to create domains for your scripts and
> alloww openvpn to domain transition to th script domain when it run the scripts.
>  That way openvpn domain does not need access to run sudo but instead the script domains
> need it.
>     
That is precisely what I have done - I created a separate domain 
(openvpn_sudo_t) and added the necessary permissions to it, though my 
SELinux knowledge is insufficient so I do not know how to 'transition' 
openvpn_t to openvpn_sudo_t and vice versa?

The new module has the proper .fe and .fc created and has the right 
permissions (I did a 'dry' run and everything runs OK), though where it 
gets a bit 'foggy' for me is how to 'link' it with openvpn_t and tell 
SELinux that it can 'transition' to and from this new domain when it 
needs to run those scripts?

> > Actually, it can - see the "touch $ROUTE_UP" statement
> in one of the
> > scripts - it executes successfully in that directory - no problem.
> >     
>
>  Are you sure its not one of the script run by init instead?
>     
Well spotted - that is exactly what happens, though the SELinux domain 
on the newly created file is openvpn_etc_rw_t (I think), so I think 
openvpn manages OK.

[Moray Henderson]

Mr Dash Four wrote:
> > A possbile slution would be to create domains for your scripts
> and
> alloww openvpn to domain transition to th script domain when it run the
> scripts.
> > That way openvpn domain does not need access to run sudo but instead 
the
> script domains need it.
> >
> That is precisely what I have done - I created a separate domain
> (openvpn_sudo_t) and added the necessary permissions to it, though my
> SELinux knowledge is insufficient so I do not know how to 'transition'
> openvpn_t to openvpn_sudo_t and vice versa? 
I've been following this thread with interest - I'm probably going to
have to set up something like similar before long.  I'm no expert
myself, but I think it works something like this:

You create two types, domain type openvpn_sudo_t and file type
openvpn_sudo_exec_t.  You make your script openvpn_sudo_exec_t, and use

domain_entry_file(openvpn_sudo_t, openvpn_sudo_exec_t)
domain_auto_trans(openvpn_sudo_exec_t, openvpn_t, openvpn_sudo_t)

in your policy module to tell openvpn_t to transition to openvpn_sudo_t
when it runs a script of type openvpn_sudo_exec_t.
 

> The new module has the proper .fe and .fc created and has the right
> permissions (I did a 'dry' run and everything runs OK), though where it
> gets a bit 'foggy' for me is how to 'link' it with openvpn_t and tell
> SELinux that it can 'transition' to and from this new domain when it
> needs to run those scripts?
>
> >> Actually, it can - see the "touch $ROUTE_UP" statement in one of the
> >> scripts - it executes successfully in that directory - no problem.
> >>
> >
> > Are you sure its not one of the script run by init instead?
> >
> Well spotted - that is exactly what happens, though the SELinux domain
> on the newly created file is openvpn_etc_rw_t (I think), so I think
> openvpn manages OK.

[Dominick Grift]

On Mon, Sep 13, 2010 at 10:19:20AM +0100, Moray Henderson wrote:
>  Mr Dash Four wrote:
>  >> A possbile slution would be to create domains for your scripts and
>  >alloww openvpn to domain transition to th script domain when it run the
>  >scripts.
>  >> That way openvpn domain does not need access to run sudo but instead
>  the
>  >script domains need it.
>  >>
>  >That is precisely what I have done - I created a separate domain
>  >(openvpn_sudo_t) and added the necessary permissions to it, though my
>  >SELinux knowledge is insufficient so I do not know how to 'transition'
>  >openvpn_t to openvpn_sudo_t and vice versa?
>  
>  I've been following this thread with interest - I'm probably going to
>  have to set up something like similar before long.  I'm no expert
>  myself, but I think it works something like this:
>  
>  You create two types, domain type openvpn_sudo_t and file type
>  openvpn_sudo_exec_t.  You make your script openvpn_sudo_exec_t, and use
>  
>  domain_entry_file(openvpn_sudo_t, openvpn_sudo_exec_t)
>  domain_auto_trans(openvpn_sudo_exec_t, openvpn_t, openvpn_sudo_t) 
probably better to use domtrans_pattern(openvpn_t, openvpn_sudo_exec_t, openvpn_sudo_t)
also make sure to declare openvpn_sudo_t a domain_type (domain_type(openvpn_sudo_t)

The domtrans example only applies for scripts run by openvpn
for script run by init youd use init_daemon_domain(openvpn_script_t,
openvpn_script_exec_t)

note different types since it does not need sudo (runs as root)

>  
>  in your policy module to tell openvpn_t to transition to openvpn_sudo_t
>  when it runs a script of type openvpn_sudo_exec_t.
>   
>  
>  >The new module has the proper .fe and .fc created and has the right
>  >permissions (I did a 'dry' run and everything runs OK), though where it
>  >gets a bit 'foggy' for me is how to 'link' it with openvpn_t and
> tell
>  >SELinux that it can 'transition' to and from this new domain when it
>  >needs to run those scripts?
>  >
>  >>> Actually, it can - see the "touch $ROUTE_UP" statement in one of
> the
>  >>> scripts - it executes successfully in that directory - no problem.
>  >>>
>  >>
>  >> Are you sure its not one of the script run by init instead?
>  >>
>  >Well spotted - that is exactly what happens, though the SELinux domain
>  >on the newly created file is openvpn_etc_rw_t (I think), so I think
>  >openvpn manages OK.
>  
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Mr Dash Four]

> > You create two types, domain type openvpn_sudo_t and file type
> > openvpn_sudo_exec_t.  You make your script openvpn_sudo_exec_t, and use
> >
> > domain_entry_file(openvpn_sudo_t, openvpn_sudo_exec_t)
> > domain_auto_trans(openvpn_sudo_exec_t, openvpn_t, openvpn_sudo_t)
> >     
>
>  probably better to use domtrans_pattern(openvpn_t, openvpn_sudo_exec_t, openvpn_sudo_t)
>  also make sure to declare openvpn_sudo_t a domain_type (domain_type(openvpn_sudo_t)
>     
I am assuming that the scripts, which are to be executed by openvpn, 
should be labelled openvpn_sudo_exec_t, right? If so, how is the file 
permission going to be set (both scripts are located in /var/lib/openvpn 
which has openvpn_etc_t type, uid:gid is set to root:_openvpn)?

>  The domtrans example only applies for scripts run by openvpn
>  for script run by init youd use init_daemon_domain(openvpn_script_t,
> openvpn_script_exec_t)
>
>  note different types since it does not need sudo (runs as root) 
Same question -
would I label the scripts executed by etc/init.d/openvpn 
openvpn_script_exec_t? As those are also in the same /var/lib/openvpn 
directory how is this file/SELinux access going to be sorted?

I also take it these new types (openvpn_sudo_exec_t, 
openvpn_script_exec_t) and the above statements need to be included in 
the new openvpn_sudo module, not openvpn, right?

[Dominick Grift]

On Mon, Sep 13, 2010 at 07:47:32PM +0100, Mr Dash Four wrote:
>  
>  >>You create two types, domain type openvpn_sudo_t and file type
>  >>openvpn_sudo_exec_t.  You make your script openvpn_sudo_exec_t, and use
>  >>
>  >>domain_entry_file(openvpn_sudo_t, openvpn_sudo_exec_t)
>  >>domain_auto_trans(openvpn_sudo_exec_t, openvpn_t, openvpn_sudo_t)
>  >
>  >probably better to use domtrans_pattern(openvpn_t, openvpn_sudo_exec_t,
> openvpn_sudo_t)
>  >also make sure to declare openvpn_sudo_t a domain_type (domain_type(openvpn_sudo_t)
>  I am assuming that the scripts, which are to be executed by openvpn,
>  should be labelled openvpn_sudo_exec_t, right? If so, how is the 
Assuming that is the executable file type you have declared for your script, yes

>  file permission going to be set (both scripts are located in
>  /var/lib/openvpn which has openvpn_etc_t type, uid:gid is set to
>  root:_openvpn)? 
You would need to specify the file context for the paths to you scripts, example:

myopenvpn.if:
/var/lib/openvpn/script1 -- gen_context(system_u:object_r:openvpn_sudo_exec_t,s0)

then reset the paths context:
restorecon -v /var/lib/openvpn/script1

When its contexts (ls -alZ /var/lib/openvpn/script1) is set to openvpn_sudo_exec_t, then
openvpn_t can execute it, provided youve defined the proper policy.

>  
>  >The domtrans example only applies for scripts run by openvpn
>  >for script run by init youd use init_daemon_domain(openvpn_script_t,
> openvpn_script_exec_t)
>  >
>  >note different types since it does not need sudo (runs as root)
>  Same question - would I label the scripts executed by
>  etc/init.d/openvpn openvpn_script_exec_t? As those are also in the
>  same /var/lib/openvpn directory how is this file/SELinux access
>  going to be sorted? 
You should use a different domain and executable file type for scripts executed by init.
because these domain do not need access to sudo.

myscript.te:

type myscript_t;
type myscript_exec_t;
init_daemon_domain(myscript_t, myscript_exec_t)

myscript.fc:

/var/lib/openvpn/myscript -- gen_context(system_u:object_r:myscript_exec_t,s0)


reset context:

restorecon -v /var/lib/openvpn/myscript1

That should allow init to domain transition to myscript_t when it runs
/var/lib/openvpn/myscript1
ofcourse its missing much policy but the above is the start.

>  
>  I also take it these new types (openvpn_sudo_exec_t,
>  openvpn_script_exec_t) and the above statements need to be included
>  in the new openvpn_sudo module, not openvpn, right?
>   
Sure, any type you use should be declared, made usable and types for files must be applied
by specifying file contexts and resetting the files to the specified contexts.

[Mr Dash Four]

> > file permission going to be set (both scripts are located in
> > /var/lib/openvpn which has openvpn_etc_t type, uid:gid is set to
> > root:_openvpn)?
> >     
>
>  You would need to specify the file context for the paths to you scripts, example:
>
>  myopenvpn.if:
>  /var/lib/openvpn/script1 -- gen_context(system_u:object_r:openvpn_sudo_exec_t,s0)
>
>  then reset the paths context:
>  restorecon -v /var/lib/openvpn/script1
>
>  When its contexts (ls -alZ /var/lib/openvpn/script1) is set to openvpn_sudo_exec_t, then
> openvpn_t can execute it, provided youve defined the proper policy.
>     
My question was more to do with the directory access - this new 
domain/type (openvpn_sudo_t and openvpn_sudo_exec_t) is placed in the 
/var/lib/openvpn directory which is labelled openvpn_etc_t and I am not 
entirely sure openvpn_sudo_t would have access to it (I know from the 
above it would have access to the file itself, but am not sure it has 
access to the directory in which this file resides - /var/lib/openvpn)?

> > Same question - would I label the scripts executed by
> > etc/init.d/openvpn openvpn_script_exec_t? As those are also in the
> > same /var/lib/openvpn directory how is this file/SELinux access
> > going to be sorted?
> >     
>
>  You should use a different domain and executable file type for scripts executed by init.
> because these domain do not need access to sudo.
>
>  myscript.te:
>
>  type myscript_t;
>  type myscript_exec_t;
>  init_daemon_domain(myscript_t, myscript_exec_t)
>
>  myscript.fc:
>
>  /var/lib/openvpn/myscript -- gen_context(system_u:object_r:myscript_exec_t,s0)
>
>
>  reset context:
>
>  restorecon -v /var/lib/openvpn/myscript1
>
>  That should allow init to domain transition to myscript_t when it runs
> /var/lib/openvpn/myscript1
>  ofcourse its missing much policy but the above is the start.
>     
That is all well and good but the same question as above - what about 
the directory access?

[Dominick Grift]

On Mon, Sep 13, 2010 at 08:07:15PM +0100, Mr Dash Four wrote:
>  
>  >>file permission going to be set (both scripts are located in
>  >>/var/lib/openvpn which has openvpn_etc_t type, uid:gid is set to
>  >>root:_openvpn)?
>  >
>  >You would need to specify the file context for the paths to you scripts, example:
>  >
>  >myopenvpn.if:
>  >/var/lib/openvpn/script1 -- gen_context(system_u:object_r:openvpn_sudo_exec_t,s0)
>  >
>  >then reset the paths context:
>  >restorecon -v /var/lib/openvpn/script1
>  >
>  >When its contexts (ls -alZ /var/lib/openvpn/script1) is set to openvpn_sudo_exec_t,
> then openvpn_t can execute it, provided youve defined the proper policy.
>  My question was more to do with the directory access - this new
>  domain/type (openvpn_sudo_t and openvpn_sudo_exec_t) is placed in
>  the /var/lib/openvpn directory which is labelled openvpn_etc_t and I
>  am not entirely sure openvpn_sudo_t would have access to it (I know
>  from the above it would have access to the file itself, but am not
>  sure it has access to the directory in which this file resides -
>  /var/lib/openvpn)? 
whether they have any access at all depends on what access you specify.
So unless you allow your new domain to interact with the type foro that location, access
is denied.

>  
>  >>Same question - would I label the scripts executed by
>  >>etc/init.d/openvpn openvpn_script_exec_t? As those are also in the
>  >>same /var/lib/openvpn directory how is this file/SELinux access
>  >>going to be sorted?
>  >
>  >You should use a different domain and executable file type for scripts executed by
> init. because these domain do not need access to sudo.
>  >
>  >myscript.te:
>  >
>  >type myscript_t;
>  >type myscript_exec_t;
>  >init_daemon_domain(myscript_t, myscript_exec_t)
>  >
>  >myscript.fc:
>  >
>  >/var/lib/openvpn/myscript -- gen_context(system_u:object_r:myscript_exec_t,s0)
>  >
>  >
>  >reset context:
>  >
>  >restorecon -v /var/lib/openvpn/myscript1
>  >
>  >That should allow init to domain transition to myscript_t when it runs
> /var/lib/openvpn/myscript1
>  >ofcourse its missing much policy but the above is the start.
>  That is all well and good but the same question as above - what
>  about the directory access?
>

[Mr Dash Four]

>  whether they have any access at all depends on what access you
> specify.
>  So unless you allow your new domain to interact with the type foro that location, access
> is denied.
>     
That's what I thought - this domain will need read access to this 
directory, but since it has already been labelled openvpn_etc_t and I 
can't add another SELinux label I need to grant openvpn_sudo_t the same 
permission to openvpn_etc_t as openvpn_t currently has (the macro name 
used to do this in openvpn.te escapes me at the moment but I will find it).

[Dominick Grift]

On Mon, Sep 13, 2010 at 08:17:53PM +0100, Mr Dash Four wrote:
>  
>  >whether they have any access at all depends on what access you specify.
>  >So unless you allow your new domain to interact with the type foro that location,
> access is denied.
>  That's what I thought - this domain will need read access to this
>  directory, but since it has already been labelled openvpn_etc_t and
>  I can't add another SELinux label I need to grant openvpn_sudo_t the
>  same permission to openvpn_etc_t as openvpn_t currently has (the
>  macro name used to do this in openvpn.te escapes me at the moment
>  but I will find it). 
Why even put it there. shouldnt it just be in /usr/sbin/ or something?
>

[Mr Dash Four]

>  Why even put it there. shouldnt it just be in /usr/sbin/ or
> something?
>     
Then I would need to grant permission to /usr/bin in both openvpn_sudo_t 
AND openvpn_t ... or am I missing something?

Also, one of the scripts creates ".route-up-started" (though that is 
executed by root and within the /etc/init.d/openvpn domain), so I am not 
sure how this is going to work out.

[Moray Henderson]

Mr Dash Four wrote:
> > Why even put it there. shouldnt it just be in /usr/sbin/ or
something?
> >
> Then I would need to grant permission to /usr/bin in both 
openvpn_sudo_t
> AND openvpn_t ... or am I missing something?
>
> Also, one of the scripts creates ".route-up-started" (though that is
> executed by root and within the /etc/init.d/openvpn domain), so I am 
not
> sure how this is going to work out. 
The way the Samba policy module does things is to define a specific
directory for scripts:

samba.fc:
...
/var/lib/samba/scripts(/.*)?
gen_context(system_u:object_r:samba_unconfined_script_exec_t,s0)
...

This way you keep the scripts separate from ordinary system binaries,
they automatically get the correct type when installed from rpm, and you
don't need to create a new file context every time you add a script.


Moray.
"To err is human.  To purr, feline"

[Mr Dash Four]

>  The way the Samba policy module does things is to define a specific
>  directory for scripts:
>
>  samba.fc:
>  ...
>  /var/lib/samba/scripts(/.*)?
>  gen_context(system_u:object_r:samba_unconfined_script_exec_t,s0)
>  ...
>
>  This way you keep the scripts separate from ordinary system binaries,
>  they automatically get the correct type when installed from rpm, and you
>  don't need to create a new file context every time you add a script.
>     
OK, but my initial question still stands - both openvpn_t and 
openvpn_sudo_t need to have access to this directory at least. So, if I 
define a new script type I have to alter openvpn.te and make the 
directory where the scripts are located (and their new domain!) 
available/accessible to openvpn_t. I have to do the same with 
openvpn_sudo_t as well.

One other possible solution would be to leave the directory where this 
scripts are as openvpn_etc_t, name the scripts with this new domain and 
then alter the new module to have (read-only) access to openvpn_etc_t 
and full access to this new domain for the scripts - in this way I am 
not altering openvpn.te (which is part of the main policy), but I am 
creating a potential security hole by granting this new domain 
(openvpn_sudo_t) access to openvpn_etc_t which includes other (mainly 
configuration) files, which belong to openvpn...not as straight-forward 
is it? Or have I missed something?

[Moray Henderson]

(Odd - I only saw my copy of this, not the one that went to the list)

Mr Dash Four wrote:
> > The way the Samba policy module does things is to define a
> specific
> > directory for scripts:
> >
> > samba.fc:
> > ...
> > /var/lib/samba/scripts(/.*)?
> > gen_context(system_u:object_r:samba_unconfined_script_exec_t,s0)
> > ...
> >
> > This way you keep the scripts separate from ordinary system binaries,
> > they automatically get the correct type when installed from rpm, and 
you
> > don't need to create a new file context every time you add a
> script.
> >
> OK, but my initial question still stands - both openvpn_t and
> openvpn_sudo_t need to have access to this directory at least. So, if I
> define a new script type I have to alter openvpn.te and make the
> directory where the scripts are located (and their new domain!)
> available/accessible to openvpn_t. I have to do the same with
> openvpn_sudo_t as well.
>
> One other possible solution would be to leave the directory where this
> scripts are as openvpn_etc_t, name the scripts with this new domain and
> then alter the new module to have (read-only) access to openvpn_etc_t
> and full access to this new domain for the scripts - in this way I am
> not altering openvpn.te (which is part of the main policy), but I am
> creating a potential security hole by granting this new domain
> (openvpn_sudo_t) access to openvpn_etc_t which includes other (mainly
> configuration) files, which belong to openvpn...not as straight-forward
> is it? Or have I missed something? 
I wouldn't alter openvpn.te from refpolicy; I leave the standard stuff
alone and create any extensions in a specific policy for my servers.

It's not difficult to make new types accessible to openvpn_t - hey, I
just discovered some new macros!  This looks as if it ought to be close:

openvpn_sudo.fc
  /var/lib/openvpn/scripts(/.*)?
gen_context(system_u:object_r:openvpn_sudo_exec_t,s0)

openvpn_sudo.te
  # Create types for script files and domain
  type openvpn_sudo_exec_t;
  type openvpn_sudo_t;
  files_type(openvpn_sudo_exec_t);
  domain_type(openvpn_sudo_t);

  # Allow openvpn_t to access and run the scripts
  exec_files_pattern(openvpn_t, openvpn_sudo_exec_t,
openvpn_sudo_exec_t);
  # perhaps we also need one or both of these
  allow openvpn_sudo_t openvpn_etc_t:dir search_dir_perms;
  exec_files_pattern(openvpn_sudo_t, openvpn_sudo_exec_t,
openvpn_sudo_exec_t);

  # Get openvpn_t to transition the scripts to the new domain
  domtrans_pattern(openvpn_t, openvpn_sudo_exec_t, openvpn_sudo_t);

You put your scripts in /var/lib/openvpn/scripts.  If the scripts are
installed from rpm and openvpn_sudo policy is already loaded, they will
automatically get the correct context.  Otherwise you use 

  restorecon -r /var/lib/openvpn/scripts

once the policy is loaded.

Assuming this works (I haven't tested it) to get your scripts accessible
and running in the right context, you would then work out whatever
access the scripts need to run, and add that to openvpn_sudo.te too.

See /usr/share/selinux/devel/include/support for the domain transition
and file permission macros.

[Mr Dash Four]

>  I wouldn't alter openvpn.te from refpolicy; I leave the standard
> stuff
>  alone and create any extensions in a specific policy for my servers.
>     
Yep, my thoughts exactly!

>  It's not difficult to make new types accessible to openvpn_t -
> hey, I
>  just discovered some new macros!  This looks as if it ought to be close:
>
>  openvpn_sudo.fc
>    /var/lib/openvpn/scripts(/.*)?
>  gen_context(system_u:object_r:openvpn_sudo_exec_t,s0)
>
>  openvpn_sudo.te
>    # Create types for script files and domain
>    type openvpn_sudo_exec_t;
>    type openvpn_sudo_t;
>    files_type(openvpn_sudo_exec_t);
>    domain_type(openvpn_sudo_t);
>
>    # Allow openvpn_t to access and run the scripts
>    exec_files_pattern(openvpn_t, openvpn_sudo_exec_t,
>  openvpn_sudo_exec_t);
>     
I haven't looked at this, but there is another macro I have been using 
called can_exec(...) - it is one of the first lines in openvpn.te

>    # perhaps we also need one or both of these
>    allow openvpn_sudo_t openvpn_etc_t:dir search_dir_perms;
>    exec_files_pattern(openvpn_sudo_t, openvpn_sudo_exec_t,
>  openvpn_sudo_exec_t);
>     
I think can_exec does all of this, not sure as I am not at the testing 
machine, but will check this out at first opportunity.

>    # Get openvpn_t to transition the scripts to the new domain
>    domtrans_pattern(openvpn_t, openvpn_sudo_exec_t, openvpn_sudo_t);
>     
Is this transition in both directions? In other words, once the 
transition from openvpn_t -> openvpn_sudo_t has been made and the 
scripts have done their job, would the old (openvpn_t) domain be 
restored then?

>  You put your scripts in /var/lib/openvpn/scripts.  If the scripts
> are
>  installed from rpm and openvpn_sudo policy is already loaded, they will
>  automatically get the correct context.  Otherwise you use 
>
>    restorecon -r /var/lib/openvpn/scripts
>
>  once the policy is loaded.
>
>  Assuming this works (I haven't tested it) to get your scripts accessible
>  and running in the right context, you would then work out whatever
>  access the scripts need to run, and add that to openvpn_sudo.te too.
>     
I will test this during the weekend because if this works it will solve 
a lot of my problems I am currently having with openvpn.

>  See /usr/share/selinux/devel/include/support for the domain
> transition
>  and file permission macros.
>     
I will look at these - thanks for posting this out!

[Moray Henderson]

Mr Dash Four wrote:
> > It's not difficult to make new types accessible to openvpn_t
> - hey, I
> > just discovered some new macros!  This looks as if it ought to be 
close:
> >
> > openvpn_sudo.fc
> >   /var/lib/openvpn/scripts(/.*)?
> > gen_context(system_u:object_r:openvpn_sudo_exec_t,s0)
> >
> > openvpn_sudo.te
> >   # Create types for script files and domain
> >   type openvpn_sudo_exec_t;
> >   type openvpn_sudo_t;
> >   files_type(openvpn_sudo_exec_t);
> >   domain_type(openvpn_sudo_t);
> >
> >   # Allow openvpn_t to access and run the scripts
> >   exec_files_pattern(openvpn_t, openvpn_sudo_exec_t,
> > openvpn_sudo_exec_t);
> >
> I haven't looked at this, but there is another macro I have been using
> called can_exec(...) - it is one of the first lines in openvpn.te
>
> >   # perhaps we also need one or both of these
> >   allow openvpn_sudo_t openvpn_etc_t:dir search_dir_perms;
> >   exec_files_pattern(openvpn_sudo_t, openvpn_sudo_exec_t,
> > openvpn_sudo_exec_t);
> >
> I think can_exec does all of this, not sure as I am not at the testing
> machine, but will check this out at first opportunity.
>
> >   # Get openvpn_t to transition the scripts to the new domain
> >   domtrans_pattern(openvpn_t, openvpn_sudo_exec_t, openvpn_sudo_t);
> >
> Is this transition in both directions? In other words, once the
> transition from openvpn_t -> openvpn_sudo_t has been made and the
> scripts have done their job, would the old (openvpn_t) domain be
> restored then? 
I would expect that the openvpn daemon running in openvpn_t would fork a
new process for the script.  The kernel would transition the new script
process to openvpn_sudo_t, leaving the openvpn daemon in openvpn_t.
When the script ends, its process ends.  Nothing should need to be
restored.

> > You put your scripts in /var/lib/openvpn/scripts.  If the scripts
> are
> > installed from rpm and openvpn_sudo policy is already loaded, they 
will
> > automatically get the correct context.  Otherwise you use
> >
> >   restorecon -r /var/lib/openvpn/scripts
> >
> > once the policy is loaded.
> >
> > Assuming this works (I haven't tested it) to get your scripts 
accessible
> > and running in the right context, you would then work out
> whatever
> > access the scripts need to run, and add that to openvpn_sudo.te too.
> >
> I will test this during the weekend because if this works it will solve
> a lot of my problems I am currently having with openvpn.
>
> > See /usr/share/selinux/devel/include/support for the domain 
transition
> > and file permission macros.
> >
> I will look at these - thanks for posting this out!