Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1297375

Summary: SELinux is preventing /usr/sbin/openvpn from 'read, write' accesses on the directory /tmp.
Product: [Fedora] Fedora Reporter: David King <amigadave>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: high    
Version: rawhideCC: dominick.grift, dwalsh, lvrabec, mgrepl, plautrba, pschindl, robatino, sgallagh
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: AcceptedBlocker
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-02-03 13:56:17 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1230435    

Description David King 2016-01-11 10:45:04 UTC
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.

Comment 1 Stephen Gallagher 2016-01-11 17:03:50 UTC
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?

Comment 2 Miroslav Grepl 2016-01-12 06:07:38 UTC
https://github.com/systemd/systemd/issues/2196

Comment 3 Fedora Blocker Bugs Application 2016-01-18 17:25:18 UTC
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.

Comment 4 Petr Schindler 2016-01-18 17:48:23 UTC
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

Comment 5 Lukas Vrabec 2016-02-03 13:56:17 UTC
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.