openvpn-down-root.so OpenVPN still runs as root

[van Heuven]

Hello,

I've got a question about the openvpn-down-root.so plugin. I'm using a
modified (deployed) version of Tunnelblick within the configuration a
forced use of the openvpn-down-root.so plugin to get openvpn running
as none root.

In de Deploy directory there's a forced-preferences.plist with (among
others) *-useDownRootPlugin checked. The log file shows that the
plugin is being loaded:
PLUGIN_CALL: POST /Applications/Tunnelblick.app/Contents/Resources/
openvpn-down-root.so/PLUGIN_UP status=0

But if i open activity monitor (or ps -ef on command line) i noticed
OpenVPN is still running as root.

What am i forgetting here?

Regards,

van Heuven

[jkbull...gmail.com]

This is the first time I've seen this, but I think I get the same results: two OpenVPN processes, each running as "root". So I think it is setting up the down-root plugin correctly. (I think having two processes is normal -- one is the regular OpenVPN process that should drop privileges, the other is the down-root "helper" process that does stay running as root.)

I don't see "GID set to nobody" and "UID set to nobody" lines in the logs, which would indicate that the "user nobody" and "group nobody" options are being processed, so I think you are correct that it isn't dropping privileges. They don't appear even at "verb 4".

I tested it using both the current version of Tunnelblick, which uses OpenVPN 2.1.4, and the first version of Tunnelblick (3.0b22) that includes this down-root ability, which uses OpenVPN 2.1_rc20. Both gave the same results. And at the time I tested it I was probably using Tiger or Leopard; now I'm testing on Snow Leopard, so perhaps that has something to do with it.

As far as I can remember, when this feature was originally added I did not check that the "User" reported by Activity Monitor and ps wasn't root. But I am pretty sure I saw the "GID set to nobody" and "UID set to nobody" lines in the logs.

Although you didn't mention it, you apparently have the proper line in the configuration file, too, or you wouldn't be getting the PLUGIN_CALL message. You also must have "user nobody" and "group nobody" in the configuration file, or some other user/group, so that privileges are actually dropped. But even if you didn't have them, I did, and I get the same results as you.

By the way, the "Using Tunnelblick" wiki is misleading about the line that should appear in the configuration file because it says the second argument to the plugin option is "path-to-client.down.osx.sh". It is actually the path to whatever the down-script is. Older versions use client.down.osx.sh, but newer versions use path-to-client.down.tunnelblick.sh by default when "Set nameserver" is selected. It should be the path to whatever down-script is actaually being used.

Maybe batmanppc can shed some light on this.

[jkbull...gmail.com]

To clarify: I tested this today on Snow Leopard. When I originally tested this feature after adding it to Tunnelblick I may have been using Tiger or Leopard. I haven't tested it recently on Tiger or Leopard.

[van Heuven]

Hi!

Thanks for your answer. I can confirm the two processes running as
root.

You mentioned the "user nobody" and the "group nobody" in the
configuration file. I actually don't have these settings. Which
configuration file must have these settings? In the client.conf i have
the following configuration:
# Downgrade privileges after initialization (non-Windows only)
;user nobody
;group nobody

By uncommenting these settings, openvpn does drop to nobody but the
down.osx.sh scripts return errors because it's run by an unprivileged
user.

[jkbull...gmail.com]

I've looked at it more closely, and there are problems with the documentation and a bug or bug in Tunnelblick itself.

First, the Using Tunnelblick wiki says you need to include the "plugin..." option in the configuration file. That shouldn't be necessary in recent versions of Tunnelblick.

But even if you include that option, Tunnelblick seems to be overriding it. I'll have more later.

[jkbull...gmail.com]

It now seems to be working for me in that it gets the "GID set to nobody" and "UID set to nobody" log entries from OpenVPN.

Activity Monitor still shows the user as "root" for both processes, but ps -ef shows the UID of one process as 0 (root) and the UID for the other process is -2 (which I think is "nobody")

So Activity Monitor isn't reflecting the fact that the privileges have been dropped. If I quit Activity Monitor and then launch it again, after the connection has been established (and privileges dropped), it shows that one User is "nobody" and one is "root", which is correct.

So if you add "user nobody" and "group nobody" to your configuration file, and wait to launch Activity Monitor after privileges have been dropped, it should work and you should see the proper users in Activity Monitor.

But there is a problem due to a bug in Tunnelblick's parsing the configuration file (which Tunnelblick does to look for the "user" and "group" options so it knows to load the plugin). It has been fixed in the source code and will be in the next bugfix release (due soon), but isn't in the version you are running. So even if you had "user nobody" and "group nobody" in your configuration files, your (latest release version of) Tunnelblick might not have seen them, so it wouldn't have used the "plugin" option.

You can remedy that by adding the plugin line to your configuration file (which was necessary in older versions of Tunnelblick). See Using openvpn-down-root.so.

[jkbull...gmail.com]

A new version of Tunnelblick (just released) should fix the configuration file parsing bug, making it unncessary to manually add the "plugin" option. Take it out and see if things start working. (Remember to launch Activity Monitor after the VPN connection is made.)

[van Heuven]

Thanks for quick the bug fix!

I updated my client.conf and added:

# Downgrade privileges after initialization (non-Windows only)
user nobody
group nobody

OpenVPN does drop privileges to user nobody but after disconnecting
the tunnel error messages apear in the log file:
route: must be root to alter routing table
2011-01-28 16:30:32 ERROR: OS X route delete command failed: external
program exited with error status: 77

I think i'm still doeing something wrong here. Is the user and group
nobody suppose to be in the client.conf (which remains in the .tblk
directory) or are they plist preferences in the (in my case) forced-
preferences.plist?

[jkbull...gmail.com]

"user nobody" and "group nobody" go in the client.conf file. But (due to a bug) you must be using Tunnelblick 3.1.3, which was released yesterday for them to work properly.

You should remove any "plugin" line in the client.conf file.

Please post your complete client.conf file and the complete log (clear the log before trying to connect). X out anything sensitive.

[van Heuven]

Hello,

Here's my configuration and log file:

Client.conf:

client
dev tun
proto udp
remote XXX.XXXXXX.XXX XXXXX
resolv-retry infinite
nobind
user nobody
group nobody
persist-key
persist-tun
ca ca.crt
cert cert.crt
key key.key
ns-cert-type server
tls-auth ta.key 1
cipher AES-256-CBC
comp-lzo
verb 3


Log file:

2011-01-31 16:33:05 *Tunnelblick: OS X 10.6.5; Tunnelblick 3.1.3
(build 2190.2305); OpenVPN 2.1.4
2011-01-31 16:33:07 *Tunnelblick: Attempting connection with
XXXXXXXXXXX; Set nameserver = 3; monitoring connection
2011-01-31 16:33:07 *Tunnelblick: /Applications/Tunnelblick.app/
Contents/Resources/openvpnstart start XXXXXXXXXXX.tblk
2011-01-31 16:33:07 *Tunnelblick: openvpnstart: /Applications/
Tunnelblick.app/Contents/Resources/openvpn --cd /Users/martijn/Library/
Application Support/Tunnelblick/Configurations/XXXXXXXXXXX.tblk/
Contents/Resources --daemon --management 127.0.0.1 XXXX --config /
Users/martijn/Library/Application Support/Tunnelblick/Configurations/
XXXXXXXXXXX.tblk/Contents/Resources/config.ovpn --log /Library/
Application Support/Tunnelblick/Logs/-SUsers-Smartijn-SLibrary-
SApplication Support-STunnelblick-SConfigurations-SXXXXXXXXXXX.tblk-
SContents-SResources-Sconfig.ovpn.X_X_X_X_XX.XXXX.openvpn.log --
management-query-passwords --management-hold --script-security 2 --up /
Applications/Tunnelblick.app/Contents/Resources/
client.up.tunnelblick.sh -m -w -d --plugin /Applications/
Tunnelblick.app/Contents/Resources/openvpn-down-root.so /Applications/
Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -m -w -d
--up-restart
2011-01-31 16:33:08 OpenVPN 2.1.4 i386-apple-darwin10.5.0 [SSL] [LZO2]
[PKCS11] built on Dec 9 2010
2011-01-31 16:33:08 MANAGEMENT: TCP Socket listening on 127.0.0.1:XXXX
2011-01-31 16:33:08 Need hold release from management interface,
waiting...
2011-01-31 16:33:08 MANAGEMENT: Client connected from 127.0.0.1:XXXX
2011-01-31 16:33:08 MANAGEMENT: CMD 'pid'
2011-01-31 16:33:08 MANAGEMENT: CMD 'state on'
2011-01-31 16:33:08 MANAGEMENT: CMD 'state'
2011-01-31 16:33:08 MANAGEMENT: CMD 'hold release'
2011-01-31 16:33:08 NOTE: the current --script-security setting may
allow this configuration to call user-defined scripts
2011-01-31 16:33:08 PLUGIN_INIT: POST /Applications/Tunnelblick.app/
Contents/Resources/openvpn-down-root.so '[/Applications/
Tunnelblick.app/Contents/Resources/openvpn-down-root.so] [/
Applications/Tunnelblick.app/Contents/Resources/
client.down.tunnelblick.sh] [-m] [-w] [-d]' intercepted=PLUGIN_UP|
PLUGIN_DOWN
2011-01-31 16:33:08 Control Channel Authentication: using 'ta.key' as
a OpenVPN static key file
2011-01-31 16:33:08 Outgoing Control Channel Authentication: Using 160
bit message hash 'SHA1' for HMAC authentication
2011-01-31 16:33:08 Incoming Control Channel Authentication: Using 160
bit message hash 'SHA1' for HMAC authentication
2011-01-31 16:33:08 LZO compression initialized
2011-01-31 16:33:08 Control Channel MTU parms [ L:1558 D:166 EF:66 EB:
0 ET:0 EL:0 ]
2011-01-31 16:33:08 Socket Buffers: R=[42080->65536] S=[9216->65536]
2011-01-31 16:33:08 MANAGEMENT: >STATE:1296487988,RESOLVE,,,
2011-01-31 16:33:08 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:
135 ET:0 EL:0 AF:3/1 ]
2011-01-31 16:33:08 Local Options hash (VER=V4): '9e7066d2'
2011-01-31 16:33:08 Expected Remote Options hash (VER=V4): '162b04de'
2011-01-31 16:33:08 NOTE: UID/GID downgrade will be delayed because of
--client, --pull, or --up-delay
2011-01-31 16:33:08 UDPv4 link local: [undef]
2011-01-31 16:33:08 UDPv4 link remote: XXX.XXX.XXX.XXX:XXX
2011-01-31 16:33:08 MANAGEMENT: >STATE:1296487988,WAIT,,,
2011-01-31 16:33:08 MANAGEMENT: >STATE:1296487988,AUTH,,,
2011-01-31 16:33:08 TLS: Initial packet from XXX.XXX.XXX.XXX:XXX,
sid=6f76576c 1f654707
2011-01-31 16:33:08 VERIFY OK: depth=1, /C=NL/ST=NH/L=XXXXXXXXXXX/
O=XXXXXXXXXXX/CN=XXXXXXXXXXX_CA/emailAddress=XXXXX...@XXXXXXX.XXX
2011-01-31 16:33:08 VERIFY OK: nsCertType=SERVER
2011-01-31 16:33:08 VERIFY OK: depth=0, /C=NL/ST=NH/L=XXXXXXXXXXX/
O=XXXXXXXXXXX/CN=server/emailAddress=XXXXX...@XXXXXXX.XXX
2011-01-31 16:33:08 Data Channel Encrypt: Cipher 'AES-256-CBC'
initialized with 256 bit key
2011-01-31 16:33:08 Data Channel Encrypt: Using 160 bit message hash
'SHA1' for HMAC authentication
2011-01-31 16:33:08 Data Channel Decrypt: Cipher 'AES-256-CBC'
initialized with 256 bit key
2011-01-31 16:33:08 Data Channel Decrypt: Using 160 bit message hash
'SHA1' for HMAC authentication
2011-01-31 16:33:08 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-
AES256-SHA, 2048 bit RSA
2011-01-31 16:33:08 [server] Peer Connection Initiated with
XXX.XXX.XXX.XXX:XXX
2011-01-31 16:33:09 MANAGEMENT: >STATE:1296487989,GET_CONFIG,,,
2011-01-31 16:33:10 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
2011-01-31 16:33:10 PUSH: Received control message:
'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS
XXX.XXX.XXX.XXX,dhcp-option DNS XXX.XXX.XXX.XXX,dhcp-option DOMAIN
XXXXXXXXX.XXX,route XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX,topology
net30,ping 10,ping-restart 120,ifconfig XXX.XXX.XXX.XXX
XXX.XXX.XXX.XXX'
2011-01-31 16:33:10 OPTIONS IMPORT: timers and/or timeouts modified
2011-01-31 16:33:10 OPTIONS IMPORT: --ifconfig/up options modified
2011-01-31 16:33:10 OPTIONS IMPORT: route options modified
2011-01-31 16:33:10 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option
options modified
2011-01-31 16:33:10 ROUTE default_gateway=XXX.XXX.XXX.XXX
2011-01-31 16:33:10 TUN/TAP device /dev/tun0 opened
2011-01-31 16:33:10 MANAGEMENT: >STATE:
1296487990,ASSIGN_IP,,XXX.XXX.XXX.XXX,
2011-01-31 16:33:10 /sbin/ifconfig tun0 delete
2011-01-31 16:33:10 NOTE: Tried to delete pre-existing tun/tap
instance -- No Problem if failure
2011-01-31 16:33:10 /sbin/ifconfig tun0 XXX.XXX.XXX.XXX
XXX.XXX.XXX.XXX mtu 1500 netmask XXX.XXX.XXX.XXX up
2011-01-31 16:33:10 PLUGIN_CALL: POST /Applications/Tunnelblick.app/
Contents/Resources/openvpn-down-root.so/PLUGIN_UP status=0
2011-01-31 16:33:10 /Applications/Tunnelblick.app/Contents/Resources/
client.up.tunnelblick.sh -m -w -d tun0 1500 1558 XXX.XXX.XXX.XXX
XXX.XXX.XXX.XXX init
No such key
2011-01-31 16:33:10 /sbin/route add -net XXX.XXX.XXX.XXX
XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX
route:
writing to routing socket:
File exists
add net XXX.XXX.XXX.XXX:
gateway XXX.XXX.XXX.XXX: File exists
2011-01-31 16:33:10 /sbin/route add -net XXX.XXX.XXX.XXX
XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX
add net XXX.XXX.XXX.XXX:
gateway XXX.XXX.XXX.XXX
2011-01-31 16:33:10 /sbin/route add -net XXX.XXX.XXX.XXX
XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX
add net XXX.XXX.XXX.XXX:
gateway XXX.XXX.XXX.XXX
2011-01-31 16:33:10 MANAGEMENT: >STATE:1296487990,ADD_ROUTES,,,
2011-01-31 16:33:10 /sbin/route add -net XXX.XXX.XXX.XXX
XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX
add net XXX.XXX.XXX.XXX:
gateway XXX.XXX.XXX.XXX
2011-01-31 16:33:10 GID set to nobody
2011-01-31 16:33:10 UID set to nobody
2011-01-31 16:33:10 Initialization Sequence Completed
2011-01-31 16:33:10 MANAGEMENT: >STATE:
1296487990,CONNECTED,SUCCESS,XXX.XXX.XXX.XXX,XXX.XXX.XXX.XXX
2011-01-31 16:33:10 *Tunnelblick client.up.tunnelblick.sh: Up to two
'No such key' warnings are normal and may be ignored
2011-01-31 16:33:10 *Tunnelblick client.up.tunnelblick.sh: Saved the
DNS and WINS configurations for later use
2011-01-31 16:33:10 *Tunnelblick client.up.tunnelblick.sh: Set up to
monitor system configuration with leasewatch
2011-01-31 16:33:10 *Tunnelblick: Flushed the DNS cache
2011-01-31 16:33:15 *Tunnelblick leasewatch: A system configuration
change was ignored because it was not relevant
2011-01-31 16:33:18 event_wait : Interrupted system call (code=4)
2011-01-31 16:33:18 TCP/UDP: Closing socket
2011-01-31 16:33:18 /sbin/route delete -net XXX.XXX.XXX.XXX
XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX

route: must be root to alter
routing table

2011-01-31 16:33:18 ERROR: OS X route delete command failed: external

program exited with error status: 77

2011-01-31 16:33:18 /sbin/route delete -net XXX.XXX.XXX.XXX
XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX

route: must be root to alter
routing table

2011-01-31 16:33:18 ERROR: OS X route delete command failed: external

program exited with error status: 77

2011-01-31 16:33:18 /sbin/route delete -net XXX.XXX.XXX.XXX
XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX

route: must be root to alter
routing table

2011-01-31 16:33:18 ERROR: OS X route delete command failed: external

program exited with error status: 77

2011-01-31 16:33:18 /sbin/route delete -net XXX.XXX.XXX.XXX
XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX

route: must be root to alter
routing table

2011-01-31 16:33:18 ERROR: OS X route delete command failed: external

program exited with error status: 77

2011-01-31 16:33:18 Closing TUN/TAP interface
2011-01-31 16:33:19 PLUGIN_CALL: POST /Applications/Tunnelblick.app/
Contents/Resources/openvpn-down-root.so/PLUGIN_DOWN status=0
2011-01-31 16:33:19 PLUGIN_CLOSE: /Applications/Tunnelblick.app/
Contents/Resources/openvpn-down-root.so
2011-01-31 16:33:19 SIGTERM[hard,] received, process exiting
2011-01-31 16:33:19 MANAGEMENT: >STATE:1296487999,EXITING,SIGTERM,,
2011-01-31 16:33:19 *Tunnelblick client.down.tunnelblick.sh: Cancelled
monitoring of system configuration changes
2011-01-31 16:33:19 *Tunnelblick client.down.tunnelblick.sh: Restored
the DNS and WINS configurations
2011-01-31 16:33:19 *Tunnelblick: Flushed the DNS cache

[jkbull...gmail.com]

Thanks.

It looks like we finally have Tunnelblick making the plugin work. It is now a matter of setting up OpenVPN and the scripts properly.

The errors are because of a limitation with the way that OpenVPN works. Since it has dropped root privileges, OpenVPN itself is unable to restore the routes. Since the down script will run as root, however, the down script can restore the routes.

I'm not too clear on this, but I think the solution is to do routing in the up and down scripts.You should consult the OpenVPN documentation on this, or maybe someone who is using openvpn-down-root.so can help (hint, hint).

If you use a Tunnelblick VPN Configuration, it is easy to include customized up/down scripts. You might want to base your scripts on the standard Tunnelblick up/down scripts, located at Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh and client.down.tunnelblick.sh. (Control-click on Tunnelblick.app and click "Show Package Contents" to see inside of Tunnelblick.app to find them.)

Please post back here when you've found a solution.

[van Heuven]

Hi!

Thanks for all your help, for me everything works now. I had some
worries about routes not being deleted (the ERROR: OS X route delete
command failed: external). But that does not seem to be a problem
because when the tun interfaces are brought down the routes also
automatically disappear.

There was a problem with DNS settings not being restored but that
seems to be working fine now! (Tunnelblick 3.1.5 (build 2190.2336) )

So the solution is, ignore the "ERROR: OS X route delete command
failed: external" message :-)

Regards,

van Heuven