On Tue, Jun 26, 2012 at 1:05 PM, Alon Bar-Lev <alon.bar...@gmail.com> wrote:

> Currently openvpn requires/endorses specifying full path in plugin
> parameter. As build system already aware of plugin location, it is
> possible to load plugin relative to this directory, so full path is not
> required nor more secured.
>
> Windows is a little more complex as user may change installation
> directory at install time, so we read plugindir location from the
> registry, installer will set this value.
>

(Sorry Alon, I must have overlooked this when it was first posted.)

I do not understand the privilege escalation risk:

   - A protected (not writable by an unprivileged user) part of Tunnelblick
   controls the options sent to any instance of OpenVPN that runs as a
   privileged user, so it sends only acceptable paths. (A computer
   administrator is the only one who can modify a configuration file, which is
   the other means of specifying a plugin path.)
   - If a user runs an instance of OpenVPN from the OpenVPN binary inside
   of Tunnelblick, it runs as the user. So it's not very different form
   running it from the command line.

Aren't other installations of OpenVPN similarly protected? Or are you
trying to protect against poorly-protected installations?

Or can the server "push" a plugin path? If allowed (I don't think it should
be) that is a much bigger problem.

Disallowing absolute paths complicates things enormously for Tunnelblick
(OpenVPN GUI for OS X) for two reasons:

   - You can have multiple, different copies of Tunnelblick (it is
   self-contained), and
   - Each copy of Tunnelblick contains multiple versions of OpenVPN, each
   with its own copy of the down-root plugin.

Currently, Tunnelblick just sends a plugin path which points to the
appropriate plugin file inside the application itself (an OS X application
like Tunnelblick is basically a folder with stuff inside it).

If absolute paths are not allowed, Tunnelblick will apparently have to
start "installing" plugins in a system-wide directory, and track separate
copies of the down-root plugin by their source (i.e., the specific copy of
Tunnelblick, and the specific version of OpenVPN the down-root plugin comes
from. It would also be impossible to deal with a user moving the
Tunnelblick application somewhere else in the file hierarchy (Most OS X
applications, including Tunnelblick can be moved around as the user
pleases.)

That seems like so much trouble (and has a risk of creating a DLL-hell
equivalent) that I will probably drop support for the down-root plugin from
Tunnelblick. I don't think that's a big problem, but it will be for some
users, and they won't be able to script their way around it.

Reply via email to