> 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. -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
