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.