Re: network-manager-openvpn

[Dan Williams <dcbw redhat com>]

On Tue, 2009-12-15 at 11:08 -0500, Matt Wilks wrote:
> On 09-12-14 06:09 PM, Dan Williams wrote:
> > On Mon, 2009-12-14 at 09:24 -0500, Matt Wilks wrote:
> >> This must have been discussed before on this list, but I'm curious the
> >> reasoning behind making network-manager-openvpn have its own GUI for
> >> configuration in the first place.  Why not offer functionality similar
> >> to the Windows/Mac clients that simply manage your connections via
> >> configuration files?  You'd get all the flexibility of OpenVPN with none
> >> of the overhead of constantly having to write patches to support /
> >> debate the inclusion of individual options.
> >
> > For a number of reasons;
> 
> Thanks for your response Dan, I appreciate you taking the time to do so.
> Allow me to make a few comments.
> 
> > 1) not everyone wants to use configuration files,
> > 2) not everyone is aware of (or cares about) the intricacies of
> > configuration options, some cannot be used with others, some require
> > others to be turned on,
> 
> Granted.  However, I would think that anyone who is attempting to
> connect to a work/school VPN is more likely to have a configuration file
> handed to them then a set of OpenVPN parameters.  That is how we do it
> with the VPN I am responsible for.

Again, the config file can be imported into NM, so the process you have
still works exactly the same way.

> > 3) GUI interfaces are often more approachable and do not preclude
> > advanced users from using config files anyway, and
> 
> I think you are making an incorrect distinction here between advanced
> and beginner users.  Using a config file does not necessarily mean that
> a user is advanced.  In our case, we distribute a config file precisely
> because so many of our users are not advanced and we don't want them
> having to fiddle around with options on various clients.
> 
> > 4) handling random config files is often problematic,
> 
> I'm not sure I understand why.  Using the model of OpenVPN-GUI or
> Tunnelblick (Windows and Mac GUIs respectively) however, you would just
> have NetworkManager monitor a directory for config files.  Could be a
> directory in the user's home (ala Tunnelblick) or a system directory
> (ala OpenVPN-GUI).  Even if the user were able to specify arbitrary
> configuration file locations, how is this any more problematic then the
> dialogs to specify the ca, key and user cert that currently exist in the
> NetworkManager GUI?

1) The config file is stored separately from the rest of the
configuration data like IP address, routing information, DNS, etc.  If
it's not available (user downloads it into ~/Downloads and then it gets
deleted when FF quits) then it's no longer available

2) root daemons accessing files in users' directories is often not
allowed by security software like SELinux or AppArmor, for good reason;
it's really hard to contain a binary and limit the attack points when
you have to allow the binary to read from all over the hard drive

3) it's a security risk on daemons that require a password in the config
file when not using stdin (ex vpnc)

4) using a config file can create temporary files that require cleanup
which doesn't always get done; if we do need to substitute certain
values (like we do with dhclient) then we need to create a temporary
config file that has to be cleaned up after the transaction is complete,
which is more housekeeping and more trouble.

> > 5) it wasnt' integrated into the consistent NetworkManager
> > configuration system.
> 
> I have to admit ignorance about the standards for configuring
> NetworkManager, but I imagine that they say something about storing
> configuration internally rather than referencing external files?

http://live.gnome.org/NetworkManagerConfiguration

The NM configuration system actually produces an abstraction over
various distro and desktop-specific configuration systems so taht you
can use your preferred configuration system.  For example, GConf,
KConfig, /etc/network/interfaces, keyfiles, ifcfg files, etc, all are
transformed into a standard format that clients can read and handle.
That allows you, from a client, to actually figure out what's going on
in a standard way instead of having to code logic for each and every
configuration system.

NM doesn't store config /internally/, but the user-settings and
system-settings services do use configuration systems like GConf or
system config files that you might consider to store the config
"internally", at least in a different format than the native config file
for openvpn.  That has some benefits; as the admin you can use tools,
behaviors, processes, and knowledge that you already have for your
distro's native configuration file format.  You can lock configuration
down using GConf or keep your scripts for fixing up /e/n/i or ifcfg
files.  That sort of thing.  If it's just a random config file from a
random daemon, you need to start creating custom rules for a lot of the
stuff that you might want to do while administering systems.

> > Now that we have good import/export capability for openvpn, it's not
> > actually that hard to use your own configs.  If there's options that
> > people use, we can also whitelist them and add them to import/export
> > even if they aren't shown in the GUI.
> 
> What prompted my initial query was the lack of support for <ca>, <cert>
> and <key> directives (supported in OpenVPN since 2.1-beta7, Nov 2005).
> They allow you to specify the key files directly in the configuration
> file, making it a self-contained configuration for a connection using
> keys to authenticate.  NetworkManager also seemed to miss the fact that
> my config required both keys and a password; not hard to manually set
> but it wasn't caught by the import.

I do believe those have been in the NM openvpn configuration for a long
time.  What specific version of NM-openvpn are you using?  I'm certainly
using a CA certificate right now to write this mail.  If you pick
"Certificates (TLS)" or "Passwords with Certificates" from the dropdown
you should be able to use the certificates and keys of your choice.
This has been the case for at least a year and a half, since before NM
0.7.x was released.

> > Just because there's a GUI doesn't preclude you from writing a config
> > file and importing it of course.
> 
> That's true, and apart from the missing config I mentioned above, I
> found it to be a relatively painless process.  Kudos!  However I don't
> see how this benefits the NetworkManager developers.  Writing a plugin
> that used external config files would be a one-time job.  As it stands
> now, each new option must be whitelisted and incorporated into the
> plugin.

The whitelisting is for security.  As a user, if you download a
configuration file and want to use it, what's to say it doesn't include
some options that make things less-secure or are malicious?  Depending
on the plugin you could send a config option for "run this script after
connection" and since the VPN plugins currently run as root, that script
gets run as root.  The configuration data cannot /necessarily/ be
trusted especially if it comes from the user session.  At the same time,
you don't want to /necessarily/ lock users out completely (that's the
discretion of the sysadmin if there is one).

Dan