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 - SELinux is preventing /usr/sbin/openvpn from 'read, write' accesses on the directory /tmp.
Summary: SELinux is preventing /usr/sbin/openvpn from 'read, write' accesses on the di...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: rawhide
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F24FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2016-01-11 10:45 UTC by David King
Modified: 2016-02-03 13:56 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-02-03 13:56:17 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

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.
Note You need to log in before you can comment on or make changes to this bug.