[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

[Openvpn-users] Wrapper script and intergration to openvpn


  • Subject: [Openvpn-users] Wrapper script and intergration to openvpn
  • From: Ewan Bhamrah Harley <ewan@xxxxxxxxxxxxxxx>
  • Date: Thu, 7 Oct 2004 22:01:00 +0100

On linux systems I use a wrapper script to launch openvpn. The initial
reason for doing this was that I wanted to start using the user, group and
chroot options, but this wasn't compatible with my existing usage of
ping-restart combined with an up/restart scripts that needed to be run as
root. So I took out the daemon option, changed ping-restart to ping-exit and
wrote a one-line shell script to launch openvpn then re-launch it when it
died. 

While this approach works as far as it goes, it has limitations so I'm
looking at producing a patch to add the functionality I'm after directly
into openvpn. Before I do so I'd appreciate comments, suggestions or
criticisms (well, polite ones anyway:-) on what I'm trying to do -
particularly concerning whether or not I've missed any security
implications. 

So, here's an overview of what I'm thinking of: The problem I'm trying to
solve is that using the user, group and chroot options can cause --up (and
other) scripts to fail as the openvpn process may lose permission to run the
scripts (if the user or group options are used) or ability to even find the
scripts (if chroot is used). 

The proposed patch is to add a 'fork' option (the option name is negotiable,
suggestions welcome) to openvpn, which would only be effective if the
'ping-restart' option had also been given. If used, it will cause openvpn to
fork at some point before any setuid/setgid/chroot calls are made. The child
will get on with establishing and running the vpn (including any change of
user Id's or chroots) while the parent simply waits for the child to exit.
If a ping-restart occours, the child exits and the parent forks a new child
to handle the restarted connection. The new child then runs appropriate
scripts (should that include the 'down' script for old connection?) while it
has root permissions, before changing uid's and chrooting again. 

To cover the various persist options, the parent will have to open
tcp/udp/tun/tap handles before forking and keep them open so that subsequent
children can inherit and use them. Assuming the parent never reads from or
writes to the relevent file descriptors, is there any way a subverted child
could use these handles to subvert it's parent?

Finally, if the child exits due to an error, instead of a ping-restart, the
parent should be able to recognise that from the child's exit code and react
accordingly. This would be handled by the parent simply examinig the child's
exit value. 

A last point concerning platform support. As far as I'm aware I, the
extensions I'm suggesting should work with all supported platforms except
windows, as windows doesn't support the user/group/chroot options in the
first place. Is that correct?


So, does the list consider extensions based on this proposal to be
practical, desirable, pointless or downright useless and I should forget it?


----
Ewan


____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users