After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 670198 - When openvpn runs in a different security context, can't access configured files
When openvpn runs in a different security context, can't access configured files
Status: RESOLVED OBSOLETE
Product: NetworkManager
Classification: Platform
Component: VPN: openvpn
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Dan Williams
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2012-02-16 09:35 UTC by Stef Walter
Modified: 2020-11-12 14:30 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
So here's the patch. I'm not totally happy with it, being that it defaults (9.01 KB, patch)
2012-02-16 10:00 UTC, Stef Walter
reviewed Details | Review

Description Stef Walter 2012-02-16 09:35:22 UTC
When running with selinux (and I imagine apparmor) openvpn executed in its own security context. That means it cannot access the files that the user configures in the network-manager-openvpn configuration dialog.

Downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=555785

We need to pass the files into the new security context. That sounds complictated and pretentious, but in reality is pretty simple:

 * At the core we are trying to make it so that openvpn cannot access most of
   the user's files, since it is a network facing service that could have
   a vulnerability.
 * It would be ideal if there was a non-file based way to pass certificates
   to openvpn running in a different security context. Although me thinks, such
   a mechanism might not be simple to implement or use...
 * So by using the above copy to a temporary file approach, we simulate such
   a mechanism for passing certificates to openvpn running in a different
   security context.

As an aside, in the bright and shiny future if the user stops storing certificate authority in files, and actually uses some sort of certificate store to select them from, we'll still probably need to write some temporary files to pass to openvpn. So this paves the way for that.
Comment 1 Stef Walter 2012-02-16 10:00:34 UTC
Created attachment 207739 [details] [review]
So here's the patch. I'm not totally happy with it, being that it defaults

to using /etc/pki as the directory for creating its the temporary transition
directories. Perhaps something in /var/run would be a good default for
selinux. Does Apparmor have a directory that it already uses for this?

Also I wonder if there's a better name that 'transition dir'?

Anyway:

Don't pass files directly to openvpn, copy to transition dir

 * Since openvpn is often running in a different security context
   than nm-openvpn-service (think selinux, apparmor), we can't
   assume that openvpn can access the files the user configured.
 * Copy them to a 'transition directory' and pass those new paths
   on the openvpn command line.
 * Use --with-transition-dir to configure this transition directory
   or --without-transition-dir to turn it off.
Comment 2 Stef Walter 2012-02-16 10:02:19 UTC
Sebastien, does apparmor also have this problem? Know of any apparmour guys who might be interested in commenting on this bug?
Comment 3 Dan Williams 2012-02-26 02:01:27 UTC
So the way this *really* needs to be done is with a certificate store.  We pass fingerprints around, *not* files.  And then our cert chooser is all nice and shiny too.  The file copying thing is really, really evil and not the right solution unfortunately.

The less ideal solution would be to add a stdin config reader to openvpn, which (like vpnc) would basically accept an openvpn config file cat-ed to stdin, which can include the certificate data itself.

But in the end, what we really do want here is a system certificate store with daemons like wpa_supplicant, openvpn, vpnc, whatever able to query for certificates and keys via fingerprints or key IDs, rather than passing paths around.  For the same reason we shouldn't be writing out temporary configuration files for these daemons (I'm looking at you, OpenSWAN...) we shouldn't be writing out temporary certificates and keys either.  We need to actually solve this and make the system better rather than hacking around the status quo.
Comment 4 Stef Walter 2012-03-09 06:19:02 UTC
Sorry for not responding right away... I agree that we should do this with a certificate store. That's a ways off though:

 * Refactor out PKCS#11 RPC from gnome-keyring into another library like
   p11-kit so that it can be used to have root services access the user's
   key storage (I'm actually working on this when i have spare moments here
   and there, because it's useful for all sorts of things).
 * Implement some sort of filter so that we can restrict which certificates
   and keys can be visible on the other side of RPC.
 * Modify OpenVPN to support PKCS#11 URIs for certificates and keys.
 * Modify OpenVPN to get CA certificates from store, whether via a PKCS#11 URI
   or via PKCS#11 trust assertions.
 * Have network-manager-openvpn pass a PKCS#11 module that's connected via RPC
   to openvpn, and pass URIs to identify which certificates or keys to use.
Comment 5 Dan Winship 2014-04-25 16:11:47 UTC
(In reply to comment #4)
> Sorry for not responding right away... I agree that we should do this with a
> certificate store. That's a ways off though

I think it's much closer now than when that comment was written. Though we may still end up needing to copy non-certificate files of some sort?

I'm going to take this off the patch-review list, but leave it open in case we do need this code later.
Comment 6 Michael Catanzaro 2016-02-13 18:12:47 UTC
Comment on attachment 207739 [details] [review]
So here's the patch. I'm not totally happy with it, being that it defaults

(Actually taking this off the patch review list.)

Oh, this bug is why I can't connect to my corporate VPN... great....
Comment 7 Dan Williams 2016-02-15 22:39:42 UTC
At least with SELinux, there's a specific directory in your homedir that is marked as readable-by-root for situations like this.  But of course during import/create the openvpn code doesn't copy files there, and there's some objection to doing so at all.  A better solution might be embedded certificates/keys.
Comment 8 André Klapper 2020-11-12 14:30:10 UTC
bugzilla.gnome.org is being shut down in favor of a GitLab instance. 
We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time.

If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/

Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).