Red Hat Bugzilla – Bug 1297375
SELinux is preventing /usr/sbin/openvpn from 'read, write' accesses on the directory /tmp.
Last modified: 2016-02-03 08:56:17 EST
SELinux is preventing /usr/sbin/openvpn from 'read, write' accesses on the directory /tmp. ***** Plugin restorecon (99.5 confidence) suggests ************************ If you want to fix the label. /tmp default label should be tmp_t. Then you can run restorecon. Do # /sbin/restorecon -v /tmp ***** Plugin catchall (1.49 confidence) suggests ************************** If you believe that openvpn should be allowed read write access on the tmp directory 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 system_u:object_r:tmpfs_t:s0 Target Objects /tmp [ dir ] Source openvpn Source Path /usr/sbin/openvpn Port <Unknown> Host lenovodave Source RPM Packages Target RPM Packages filesystem-3.2-35.fc24.x86_64 Policy RPM selinux-policy-3.13.1-165.fc24.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name lenovodave Platform Linux lenovodave 4.4.0-0.rc8.git3.1.fc24.x86_64 #1 SMP Fri Jan 8 17:33:59 UTC 2016 x86_64 x86_64 Alert Count 3 First Seen 2015-12-18 14:33:36 GMT Last Seen 2016-01-11 10:25:41 GMT Local ID 66972dea-62cd-46ce-8ba0-daef64e4e465 Raw Audit Messages type=AVC msg=audit(1452507941.998:644): avc: denied { read write } for pid=10178 comm="openvpn" name="/" dev="tmpfs" ino=14696 scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir permissive=0 Hash: openvpn,openvpn_t,tmpfs_t,dir,read,write In GNOME, when trying to connect using the built-in VPN support (which uses NetworkManager), I get an AVC denial after entering my password.
To add to this: it seems that /tmp gets reassigned to tmpfs_t on each reboot, which causes problems like the above VPN issue. I'm not really sure what service is causing this to happen, but my guess would be tmpfiles.d?
https://github.com/systemd/systemd/issues/2196
Proposed as a Blocker for 24-final by Fedora user sgallagh using the blocker tracking app because: "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test." The VPN software cannot make a connection, which is critical functionality.
Discussed at 2016-01-18 blocker review meeting: [1]. This bug was accepted as a Final blocker: This bug violates the final criterion " All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use.", VPN connection is considered 'typical use' of networking [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2016-01-18/f24-blocker-review.2016-01-18-17.02.html
Seems like systemd folks fix this issue. For more information you can visit https://github.com/systemd/systemd/issues/2196. I'm closing this BZ like NOTABUG due to this is not bug in selinux distro policy. I believe this fix will be in next systemd rawhide release. Thank you.