Summary: SELinux is preventing /usr/sbin/openvpn "read" access on --------.crt. Detailed Description: [SELinux is in permissive mode. This access was not denied.] SELinux denied access requested by openvpn. It is not expected that this access is required by openvpn and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug report. Additional Information: Source Context system_u:system_r:openvpn_t:s0 Target Context unconfined_u:object_r:user_home_t:s0 Target Objects ---------.crt [ file ] Source openvpn Source Path /usr/sbin/openvpn Port <Unknown> Host (removed) Source RPM Packages openvpn-2.1.1-2.fc13 Target RPM Packages Policy RPM selinux-policy-3.9.5-7.fc14 Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Plugin Name catchall Host Name (removed) Platform Linux (removed) 2.6.35.6-37.fc14.i686 #1 SMP Fri Oct 1 06:20:51 UTC 2010 i686 i686 Alert Count 2 First Seen Fri 01 Oct 2010 09:31:13 PM CEST Last Seen Fri 01 Oct 2010 09:31:13 PM CEST Local ID 083f1a45-61a8-40ae-bfd0-9ba63ebc6450 Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1285961473.933:23390): avc: denied { read } for pid=4674 comm="openvpn" name="---------.crt" dev=sdb2 ino=360451 scontext=system_u:system_r:openvpn_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file node=(removed) type=AVC msg=audit(1285961473.933:23390): avc: denied { open } for pid=4674 comm="openvpn" name="---------.crt" dev=sdb2 ino=360451 scontext=system_u:system_r:openvpn_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file node=(removed) type=SYSCALL msg=audit(1285961473.933:23390): arch=40000003 syscall=5 success=yes exit=6 a0=bfaa5e97 a1=8000 a2=1b6 a3=bfaa3f79 items=0 ppid=4672 pid=4674 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) #Comments. SELinux is preventing NetworkManager-openvpn plugin from reading certs in my stored within my home directory Hash String generated from catchall,openvpn,openvpn_t,user_home_t,file,read audit2allow suggests: #============= openvpn_t ============== allow openvpn_t user_home_t:file { read open };
It also prevents the search access Summary: SELinux is preventing /usr/sbin/openvpn "search" access on ------. Detailed Description: [SELinux is in permissive mode. This access was not denied.] SELinux denied access requested by openvpn. It is not expected that this access is required by openvpn and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug report. Additional Information: Source Context system_u:system_r:openvpn_t:s0 Target Context unconfined_u:object_r:user_home_t:s0 Target Objects ------ [ dir ] Source openvpn Source Path /usr/sbin/openvpn Port <Unknown> Host localhost.localdomain Source RPM Packages openvpn-2.1.1-2.fc13 Target RPM Packages Policy RPM selinux-policy-3.9.5-7.fc14 Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Plugin Name catchall Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.35.6-37.fc14.i686 #1 SMP Fri Oct 1 06:20:51 UTC 2010 i686 i686 Alert Count 34 First Seen Fri 01 Oct 2010 09:08:01 PM CEST Last Seen Fri 01 Oct 2010 10:05:41 PM CEST Local ID 892adb5b-2cf9-436a-ad34-314d75c312eb Line Numbers Raw Audit Messages node=localhost.localdomain type=AVC msg=audit(1285963541.846:23443): avc: denied { search } for pid=8611 comm="openvpn" name="------" dev=sdb2 ino=360450 scontext=system_u:system_r:openvpn_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir node=localhost.localdomain type=AVC msg=audit(1285963541.846:23443): avc: denied { read } for pid=8611 comm="openvpn" name="------.crt" dev=sdb2 ino=360451 scontext=system_u:system_r:openvpn_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file node=localhost.localdomain type=AVC msg=audit(1285963541.846:23443): avc: denied { open } for pid=8611 comm="openvpn" name="------.crt" dev=sdb2 ino=360451 scontext=system_u:system_r:openvpn_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file node=localhost.localdomain type=SYSCALL msg=audit(1285963541.846:23443): arch=40000003 syscall=5 success=yes exit=6 a0=bfd4ee97 a1=8000 a2=1b6 a3=bfd4cf09 items=0 ppid=8608 pid=8611 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) =========================== #Certificate dir and filename removed
If you put your cert files into .cert or .pki it should work. SELinux sets up default labeling for these directories to be home_cert_t which openvpn is allowed to read. You might need to run restorecon on those directories. If you want to leave the cert in a different directory/path, you need to label it as home_cert_t. # semanage fcontext -a -t home_cert_t PATHTOCERT # restorecon -v PATHTOCERT
It worked, but what worries me is that this change in SELinux policy breaks both NetworkManager clients ability to connect to the VPN (i guess the same things can happen with other vpn plugins) While it's no problem for me to restore/change context of some files you'll get flooded with similar reports and users again declare SELinux broken because it gets in their way. In fact users shoulnd't see any AVC denials unless there's real threat, especially if they're using just stock distro packages. I think passing some info to the devs responsible for gnome/kde NM client might save lots of pain. I guess NM should create such dir ($HOME/.cert), copy all the necessary files and point vpn software to that location.
Lets get their comments.
I had the same problem :) I don't know if NM moving certs around is a good idea because it's sensitive data, and it would be bad to have it in a directory I don't know about.
I would guess that NetworkManager could recommend a directory to put these files.
NM only copies certificates if you make the VPN connection "available to all users" which we don't (by default) support at this time. I really, really want a system certificate store that can handle user certs too, which would fix this issue. But for now, NM simply uses the path to the certificate that the openvpn config files specifies and passes that to openvpn (which of course runs as root) because there's nothing else we really can do. We'd need to modify openvpn to use NSS and accept certificate/key fingerprints and then have openvpn go ask NSS for the actual certificates. Until then, we have to pass pathnames around. So I'm not sure where to direct this bug. I don't think it's an NM thing because NM would simply use the certificate infrastructure (if we had any). It might be an openvpn thing because openvpn can only handle paths to certificates at this time, although you can embed base64 certificate/key data into the configuration, but that still involves a root process (NetworkManager) reading the certificate. In the end the only thing that really fixes this is a system certificate store which process like wpa_supplicant, NM, vpnc, etc can all talk to instead of passing around file paths.
I'm not sure this is up to NM guys, based on current status: 1. I didn't know that ~/.cert was a "safe place" to put my files. 2. I fixed it as the selinux troubleshooting tool recommends, and it was wrong in that case because it should have informed me about the ~/.cert directory. 3. A dot directory is unfriendly, I wonder how many desktop users know about them, but it's true that using a VPN it's kind of advanced stuff :) 4. The obvious solution for most users I bet it'll be to disable selinux, and we don't want that, do we? So I wouldn't be here, in this bug report, if selinux troubleshooter had managed to advice me about the ~/.cert directory. I don't know if NM guys have to advertise 'the right place to put the cert files', because that's just according to selinux. What do you think?
Can we get the openvpn config file recommend a safe place to store the certificate. /etc/pki/... for system accounts ~/.pki or ~/.cert for homedirs. Maybe suggest to run restorecon -R -v on the path when done.
This is a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=638691 bug. Can someone merge this?
*** This bug has been marked as a duplicate of bug 638691 ***