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.