Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: Configure the network-manager OpenVPN plugin to use a key located somewhere other than ~/.certs, and selinux blocks access. SELinux is preventing /usr/sbin/openvpn from 'open' accesses on the file /home/mjg59/priv/vpn/nebula-vpn.p12. ***** Plugin openvpn (47.5 confidence) suggests **************************** If you want to mv nebula-vpn.p12 to standard location so that openvpn can have open access Then you must move the cert file to the ~/.cert directory Do # mv /home/mjg59/priv/vpn/nebula-vpn.p12 ~/.cert # restorecon -R -v ~/.cert ***** Plugin openvpn (47.5 confidence) suggests **************************** If you want to modify the label on nebula-vpn.p12 so that openvpn can have open access on it Then you must fix the labels. Do # semanage fcontext -a -t home_cert_t /home/mjg59/priv/vpn/nebula-vpn.p12 # restorecon -R -v /home/mjg59/priv/vpn/nebula-vpn.p12 ***** Plugin catchall (6.38 confidence) suggests *************************** If you believe that openvpn should be allowed open access on the nebula-vpn.p12 file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep openvpn /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:openvpn_t:s0 Target Context unconfined_u:object_r:user_home_t:s0 Target Objects /home/mjg59/priv/vpn/nebula-vpn.p12 [ file ] Source openvpn Source Path /usr/sbin/openvpn Port <Unknown> Host (removed) Source RPM Packages openvpn-2.2.2-9.fc18.x86_64 Target RPM Packages Policy RPM selinux-policy-3.11.1-62.fc18.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 3.6.9-4.fc18.x86_64 #1 SMP Tue Dec 4 14:12:51 UTC 2012 x86_64 x86_64 Alert Count 9 First Seen 2012-12-18 21:37:44 EST Last Seen 2012-12-26 12:24:09 EST Local ID fad63f98-f3ec-4d09-b748-2e39f4ceed61 Raw Audit Messages type=AVC msg=audit(1356542649.738:456): avc: denied { open } for pid=28953 comm="openvpn" path="/home/mjg59/priv/vpn/nebula-vpn.p12" dev="sda4" ino=2621505 scontext=system_u:system_r:openvpn_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file type=SYSCALL msg=audit(1356542649.738:456): arch=x86_64 syscall=open success=no exit=EACCES a0=7fff000eff2f a1=0 a2=1b6 a3=238 items=0 ppid=28951 pid=28953 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=openvpn exe=/usr/sbin/openvpn subj=system_u:system_r:openvpn_t:s0 key=(null) Hash: openvpn,openvpn_t,user_home_t,file,open audit2allow audit2allow -R Additional info: hashmarkername: setroubleshoot kernel: 3.6.9-4.fc18.x86_64 type: libreport Potential duplicate: bug 849784
In this case you will need to add the following labeling # semanage fcontext -a -e /home/mjg59/.cert /home/mjg59/priv/vpn # restorecon -R -v /home/mjg59/priv/vpn/
No. Valid software configurations must work without additional user involvement. The alternatives are either for selinux to permit this or for NM to forbid the use of files in locations other than those understood by selinux.
Well then we must either allow openvpn to read any file within the users homedir or change networkmanager
The cert file is stored in home folder Package: (null) OS Release: Fedora release 18 (Spherical Cow)
Network Manager still has no mechanism for indicating or enforcing this policy, and given that it's the default tool for OpenVPN setups the selinux policy should be relaxed until that changes.
What we really want is a certificate store so NM can just pass fingerprints down to openvpn, which then reads them from the cert store (via openssl or gnutls and pkcs#11 modules or something). Having root services read file paths isn't very nice, but changing NetworkManager doesn't help here since NM would just end up being the thing that punches the holes or reads your files instead. Best case: when creating a connection, you have to import your certificates to the cert store. The NM UI then saves the cert/key fingerprints, and that's what gets sent to openvpn, wpa_supplicant, vpnc, or whatever. Those services then ask openssl/gnutls to do whatever needs to be done using the fingerprint for the reference instead of the raw certificate/key blob data or a file path. The open question is how gnutls/openssl access the certificate store, if the certificate store is per-user.
Description of problem: Fedora 18 x86-64 Cinnamon DM. Openvpn cannot access the ca.crt. This is the only Linux distro that I get these errors with Not much else I can tell you at this time except You Guys make the World a Better Place. Sure wish I felt that way about our Goverment. Additional info: reporter: libreport-2.1.4 hashmarkername: setroubleshoot kernel: 3.9.6-200.fc18.x86_64 type: libreport
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
I ran into this problem today after upgrading to Fedora 30. Last time around, I "solved" this by disabling selinux entirely. Maybe this bug ought to be reopened? I'd be happy even with something in the VPN settings informing me that I made the wrong choice for where to put the files.