Best practices for scripting openconnect

[David Woodhouse]

On Fri, 2012-05-25 at 08:01 -0700, Jon Dufresne wrote:
> What is the best way to handle a script run by a normal user, but still
> able to establish the VPN connection. I want to limit the use of sudo
> and root as much as possible.

You didn't specify, but I'm assuming you're doing this under Linux.

You will need root privileges if you want to:
 - Create a tun device.
 - Configure a tun device.
 - Tear down the tun device and restore old routing/resolv.conf.

When invoked from NetworkManager, openconnect does *none* of those
things, and does not run as root. The device is created for it in
advance (ip tuntap create dev vpn0 mode tun user foo), and instead of
running vpnc-script to do the configuration and teardown directly, it
runs a simple replacement that *just* sends all the information back to
NetworkManager to do the setup.

So yes, it's entirely possible to run openconnect without root
privileges at all.

Let's look at how you can eliminate each of those stages...

If the IP addresses you get on the VPN are *static*, then you do the
creation *and* configuration of the interface in advance. OpenConnect
just starts to send/receive packets when it's run and it attaches to the
appropriate tun device. I suspect that's not likely to work for you, but
I mention it for completeness.

Another option is to create the interface in advance ('ip tuntap add',
as above), and run openconnect as an unprivileged user but use a setuid
wrapper around vpnc-script, since that's the thing that needs the root
privs. That's probably not what I'd do, but it's a possibility if you
definitely need to use the VPN's DNS.

You can almost certainly eliminate the *teardown* step though, and then
'openconnect --setuid' would work. If you don't change the DNS setup to
use the VPN's DNS servers, and if you don't change your *default* route
to go via the VPN, then there's nothing to tear down. If there's just
the tun device with a simple route to one subnet like 172.16.0.0/20,
then it'll just go away naturally when openconnect exits, and everything
will be back to normal. So you could use 'openconnect --setuid' with
your own little script which is a *wrapper* around vpnc-script, and just
clears the INTERNAL_IP4_DNS variable and sets its own CISCO_SPLIT_INC*
variables to route just the IP addresses/subnets you need, before
invoking the real vpnc-script.

You still need to invoke openconnect as root for that though. And you
wouldn't get VPN DNS, although your scripts *could* manually look up
things on the VPN's DNS servers and access services by IP address — the
servers would be *reachable*, but just not listed in /etc/resolv.conf.

But really, the best answer to this involves a small amount of
development work. See the '--script-tun' option to openconnect.
Basically, *instead* of opening a kernel tun device and making changes
to the system's networking configuration, it can just pass all its IP
packets to/from a program of your choice, over a UNIX domain socket.

In the past I've created such a program based in the lwIP stack, so it's
basically like a virtual machine connected to the VPN *without*
affecting the host's networking at all. I've had it responding to 'ping'
requests and was able to connect to the lwIP test services. All you need
to do to make it complete is have it listen on port 1080 of the 'real'
localhost, and act as a SOCKS server, accepting real connections from
the host and proxying them to lwIP sockets talking to the VPN...

Then you run openconnect using this, with no privs at all, and it
provides SOCKS access to everywhere inside the VPN.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120525/80c28f49/attachment.bin>