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. >
Attachment:
pgpVWnx3nxlC1.pgp
Description: PGP signature
-- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
