Description of problem: openvpn client (through NetworkManager) doesn't work. It fails to load the CA certificate: Jan 15 19:00:29 plum nm-openvpn[2918]: Cannot load CA certificate file /etc/open vpn/vpn01_cacert.pem path (null) (SSL_CTX_load_verify_locations): error:0200100D :system library:fopen:Permission denied: error:2006D002:BIO routines:BIO_new_fil e:system lib: error:0B084002:x509 certificate routines:X509_load_cert_crl_file:s ystem lib strace shows (in the child openvpn process): open("/etc/openvpn/vpn01_cacert.pem", O_RDONLY) = -1 EACCES (Permission denied) There is no sealert, and nothing logged to /var/log/audit/audit.log, but turning selinux to permissive mode allows this to work. (Have tried putting the files under /home/, and also set openvpn_enable_homedirs to on - didn't make a difference) Version-Release number of selected component (if applicable): selinux-policy-3.6.32-66.fc12.noarch selinux-policy-targeted-3.6.32-66.fc12.noarch NetworkManager-0.7.997-2.git20091214.fc12.x86_64 NetworkManager-openvpn-0.7.996-4.git20090923.fc12.x86_64 openvpn-2.1.1-2.fc12.x86_64 How reproducible: Always Steps to Reproduce: 1. Configure openvpn client connection, with password auth, ca .pem and a .key file 2. Try to connect Actual results: Fails, logs above message to syslog Expected results: Connects.
What avc message are you seeing? ausearch -m avc -ts recent Have you made sure it is labeled correctly? restorecon -R -v /etc/openvpn
(In reply to comment #1) > What avc message are you seeing? > > ausearch -m avc -ts recent No change before vs after. However disabling selinux enforcement does fix this; I just tried disabling selinux based on the strace. > Have you made sure it is labeled correctly? > > restorecon -R -v /etc/openvpn Oops - that fixes it - it was unconfined_u:object_r:user_tmp_t:s0. If that access was meant to be unaudited, then close as INVALID
--- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This is still broken ... when using NetworkManager-openvpn. Easy to reproduce by setting up an openvpn connection in nm-connection-editor. Select a CA certificate that lives in your home directory. Feb 9 17:08:50 stef-redhat nm-openvpn[6865]: Cannot load CA certificate file /data/keys/redhat-newca.crt path (null) (SSL_CTX_load_verify_locations): error:0200100D:system library:fopen:Permission denied: error:2006D002:BIO routines:BIO_new_file:system lib: error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib This could be either a selinux bug or a NetworkManager bug.
Oh, and what's worse is that this doesn't get reported by the SELinux Troubleshooter so it's really hard to track down the source of this problem.
Nothing appeared in audit.log by default. After using semodule -DB, got this in the audit.log: [root@stef-redhat data]# grep openvpn /var/log/audit/audit.log type=AVC msg=audit(1328805900.013:514): avc: denied { open } for pid=10078 comm="openvpn" name="redhat-newca.crt" dev=dm-3 ino=14811138 scontext=system_u:system_r:openvpn_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file type=SYSCALL msg=audit(1328805900.013:514): arch=c000003e syscall=2 success=yes exit=6 a0=7ffffdd48f0d a1=0 a2=1b6 a3=238 items=0 ppid=10074 pid=10078 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) type=AVC msg=audit(1328806985.085:581): avc: denied { rlimitinh } for pid=10445 comm="openvpn" scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:system_r:openvpn_t:s0 tclass=process type=AVC msg=audit(1328806985.085:581): avc: denied { siginh } for pid=10445 comm="openvpn" scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:system_r:openvpn_t:s0 tclass=process type=AVC msg=audit(1328806985.085:581): avc: denied { noatsecure } for pid=10445 comm="openvpn" scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:system_r:openvpn_t:s0 tclass=process type=SYSCALL msg=audit(1328806985.085:581): arch=c000003e syscall=59 success=yes exit=0 a0=2162c00 a1=2163940 a2=7fff0aa679f8 a3=0 items=0 ppid=10416 pid=10445 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) type=AVC msg=audit(1328806985.287:582): avc: denied { read } for pid=10445 comm="openvpn" name="redhat-newca.crt" dev=dm-3 ino=14811138 scontext=system_u:system_r:openvpn_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file type=SYSCALL msg=audit(1328806985.287:582): arch=c000003e syscall=2 success=no exit=-13 a0=7fffe7e87f0d a1=0 a2=1b6 a3=238 items=0 ppid=10416 pid=10445 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) Reopening.
Discussion on IRC about how to fix this. <stefw> dwalsh: yes, thanks. tracking down a NetworkManager-openvpn problem <dwalsh> stefw, Most likely cert file not labeled correctly in homedir. <stefw> yeah, but gathering the info to reopen the bug. obviously it's a bug in either network manager or selinux-targetted-policy, if the user selects a file, and then selinux prevents it from working all without any sort of indication of what's wrong. exactly the sort of thing that makes people turn selinux off for good :S <morphine> heh... SELinux is a harsh mistress. A very hot, steamy one. Who also likes whips and chains. problem stems from the fact that troubleshooting it isn't easy although the system itself isn't *that* complicated <dwalsh> stefw, Yes I think the gui should be made smart enough to either move the cert file to the proper location or change the label on the cert file. <dwalsh> I think there is an open bugzilla on this. and Yes this has bitten us in the past, which Is why I see openvpn, I kind of know what the problem is. ~/.cert or ~/.pki are the correct directory for these. <grift> just dont make it change labels we have tom many hard coded stuff as is <dwalsh> Yes I think it telling you that it is moving the cert to ~/.cert directory would be the proper fix. <stefw> dwalsh: so after moving the certificate into ~/.pki, am i expected to relabel? sorry for all the newb questions :) <grift> restorecon -R -v ~/.pki just to be sure <dwalsh> stefw, Correct, when in doubt restorecon. <stefw> so if network manager was fixed to place a certificate in the right place, it would also have to run a restorecon? <grift> listen , theres some things to consider when you mv a file you mv its security context with it if you cp instead of mv then the target will inherit the type of the parent dir instead <dwalsh> stefw, Yes <dwalsh> and grift is right, if you cp/rm versus mv, the correct thing is likely to happen. <stefw> aha END of IRC A more usable fix might be for NetworkManager-openvpn to always copy all files that it passes to openvpn before establishing the connection. In other words, don't tell the user about it, and expect them to understand, but imagine the copy as a way of passing files to the openvpn process running with different credentials.
I just checked in an updated policy that will get you to hit the open access violation. Then I am modifying setroubleshoot to better handle this error.
Created attachment 560722 [details] Here is the text version of what it would output.
Nice. Thanks. So I guess the next step for this bug would be to reassign to network-manager-openvpn and see if we can find a solution so that selinux violation isn't triggered at all. FWIW, OpenVPN is the perfect posterchild for an application that needs to be 'sandboxed': It's running as root, and has comlpex code with many possible avenues for misconfiguration and security issues.
NetworkManager-openvpn-0.9.0-1.fc16.x86_64 selinux-policy-targeted-3.10.0-75.fc16.noarch openvpn-2.2.1-2.fc16.x86_64
Dan Williams. I think it would be best if the tool that opens the certificate copied it into the ~/.cert directory and ran restorecon on it. Then this would just work. Maybe tell the user that you are doing this.
Is there a reason to involve the user? Obviously just using an alternate path without informing the user could cause confusion... But what about just copying the certificate to a the 'right' directory (perhaps a hidden subdirectory of ~/.cert) right before running openvpn, and then deleting the copy after? To break this down further: * 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.
That is fine with me also.
Upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=670198
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 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 this bug is closed as described in the policy above. 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 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 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.
Just hit this issue with Fedora Workstation 22 and the Red Hat OpenVPN config, is the 'fix' at to set SELinux to permisive?
Turns out this was a labeling issue because the cert was in ~/Downloads originally. But the original NetworkManager openvpn plugin problem has never been fixed. it should copy to ~/.cert itself to ensure the label is correct. irc conversation: <cschalle_> did SELinux policy change in FW22 compared to FW21? I am suddenly hitting this bug -https://bugzilla.redhat.com/show_bug.cgi?id=555785 <halfline> cschalle_: do you know the path of the file that's failing to load ? <halfline> is it /etc/openvpn/vpn01_cacert.pem ? <cschalle_> no <cschalle_> it is /home/cschalle/newca.crt <cschalle_> err <cschalle_> I mean /home/cschalle/.cert/newca.crt <halfline> what is the output of ls -lZ ~/.cert/newca.crt ? <cschalle_> halfline, the file is fine, if I change selinux to permisive it works perfectly <halfline> i want to know the security context of the file <halfline> i believe the file contents are fine <halfline> i just think it may be labelled incorrectly <cschalle_> -rw-rw-r--. 1 cschalle cschalle unconfined_u:object_r:home_root_t:s0 1338 May 6 16:07 /home/cschalle/.cert/newca.crt <halfline> okay yea that looks wrong <halfline> if you run restorecon -R ~/.cert <halfline> then rerun ls -lZ ~/.cert/newca.crt <halfline> does the label change ? <cschalle_> -rw-rw-r--. 1 cschalle cschalle unconfined_u:object_r:home_cert_t:s0 1338 May 6 16:07 /home/cschalle/.cert/newca.crt <halfline> that looks better <halfline> so from this point on you should be able to use enforcing mode <halfline> but the question is, why is the label wrong? <halfline> the bug report actually never shows network manager getting fixed <halfline> it just got closed of old age <halfline> but the cert is in the right place which is a change from the original report <halfline> it's got the wrong label though <halfline> that makes me think, that perhaps network manager was fixed at some point, and then changed how it put the cert down <halfline> in a way that regressed <halfline> home_root_t sounds like maybe network manager is first creating the file in ~ directly <halfline> then running rename() to move it to ~/.cert <cschalle_> halfline, actually this is the file I downloaded from RH, so it was originally in ~/Download and then I moved it into .cert <halfline> ah okay <halfline> that explains it <halfline> and did you use "mv" ? <cschalle_> yes <halfline> right, so if you had used cp instead i think it would have worked fine <halfline> or mv -Z <halfline> the problem is mv doesn't update the label of the file to what it's supposed to be at the new destination <halfline> it instead keeps the original label in place <cschalle_> so its a bug in mv? <halfline> it's a design flaw in mv <halfline> but others disagree and think it's the correct behavior
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
this error still occurs with Fedora 23. This is easily reproducible using Torguard openvpn configuration zip - http://torguard.net/downloads/TorGuardPRO.zip (and following these instructions - https://torguard.net/knowledgebase.php?action=displayarticle&id=53)
Same problem in Fedora 24. Created a new .pem in Downloads, tried to use the GUI, but it failed. Had to create the .cert folder and move the .pem folder into it, then the VPN connection could start. The GUI should move the .pem into the .cert folder, and if the folder doesn't exist, it should create it automatically. C'mon guys. Fix this already. Do you want linux to get better or not? You should be embarrassed. Please fix, Lubomir Rintel, and if you're not, hand it over to someone that still cares. Thanks!
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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 got bitten by this bug in Fedora release 29 (Twenty Nine). NetworkManager-openvpn fails to do anything sensible if the certificates are not correctly labelled from the SELinux point of view. Could we get the bug re-opened, please? Also, if no-one cares enough to code a fix for the bug, then could we please have GUI accept only certificate/key files stored under ~/.pki and/or ~/.cert (or whatever is the "right" location for these) *AND* either run restorecon for the user or flash big, jumping, blinking magenta-on-cyan instruction for the user that he has to do it or the VPN won't work?
Just to note that I encounter the exact same bug, but with NetworkManager-openfortivpn I'm on fedora 30
Fedora 30 here. Using Gnome NetworkManager, adding an OpenVPN connection by using "Import from file...", this extracts 3 ca,cert,key files in ~/.cert folder, however selinux blocks access for some reason. type=AVC msg=audit(1564657272.306:2066): avc: denied { search } for pid=6723 comm="openvpn" name="username" dev="nvme0n1p8" ino=17956865 scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=0
(In reply to Demi B from comment #27) > Fedora 30 here. Using Gnome NetworkManager, adding an OpenVPN connection by > using "Import from file...", this extracts 3 ca,cert,key files in ~/.cert > folder, however selinux blocks access for some reason. > > > type=AVC msg=audit(1564657272.306:2066): avc: denied { search } for > pid=6723 comm="openvpn" name="username" dev="nvme0n1p8" ino=17956865 > scontext=system_u:system_r:openvpn_t:s0 > tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=0 I think i figured it out, it was my fault, had to run restorecon on the whole home-dir.