GNOME Bugzilla – Bug 670198
When openvpn runs in a different security context, can't access configured files
Last modified: 2020-11-12 14:30:10 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.
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.
Sebastien, does apparmor also have this problem? Know of any apparmour guys who might be interested in commenting on this bug?
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.
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.
(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 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....
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.
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).