Bug 1286964 - BUG: systemd is not setting the correct SELinux label on /tmp
BUG: systemd is not setting the correct SELinux label on /tmp
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
24
x86_64 Unspecified
high Severity high
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
abrt_hash:c8fe8dabcdcac4eab4b440fc8b3...
:
: 1286239 1287005 1288773 1288775 1288777 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-12-01 04:03 EST by Petr Schindler
Modified: 2016-08-08 02:06 EDT (History)
21 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-08-08 02:06:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Petr Schindler 2015-12-01 04:03:57 EST
Description of problem:
This sealert appeared when I connected over openvpn.
SELinux is preventing openvpn from read, write access 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                   openvpn
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           filesystem-3.2-35.fc24.x86_64
Policy RPM                    selinux-policy-3.13.1-160.fc24.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     (removed)
Platform                      Linux (removed) 4.4.0-0.rc2.git2.1.fc24.x86_64 #1
                              SMP Wed Nov 25 16:43:23 UTC 2015 x86_64 x86_64
Alert Count                   1
First Seen                    2015-12-01 09:57:31 CET
Last Seen                     2015-12-01 09:57:31 CET
Local ID                      7311a08a-4160-4e05-b3ab-6806fcabeba7

Raw Audit Messages
type=AVC msg=audit(1448960251.597:706): avc:  denied  { read write } for  pid=4248 comm="openvpn" name="/" dev="tmpfs" ino=15684 scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir permissive=1


Hash: openvpn,openvpn_t,tmpfs_t,dir,read,write

Version-Release number of selected component:
selinux-policy-3.13.1-160.fc24.noarch

Additional info:
reporter:       libreport-2.6.3
hashmarkername: setroubleshoot
kernel:         4.4.0-0.rc2.git2.1.fc24.x86_64
type:           libreport
Comment 1 Vít Ondruch 2015-12-01 05:45:33 EST
Description of problem:
Trying to connect to OpenVPN via NM

Version-Release number of selected component:
selinux-policy-3.13.1-160.fc24.noarch

Additional info:
reporter:       libreport-2.6.3
hashmarkername: setroubleshoot
kernel:         4.3.0-1.fc24.x86_64
type:           libreport
Comment 2 Vít Ondruch 2015-12-01 05:46:33 EST
*** Bug 1286239 has been marked as a duplicate of this bug. ***
Comment 3 Vít Ondruch 2015-12-01 05:48:09 EST
BTW bug 1287005 seems to be related
Comment 4 Adam Williamson 2015-12-04 19:49:38 EST
I also see this on Rawhide, and indeed doing this:

restorecon -vr /tmp

solves the problem temporarily and lets you connect. But I didn't change the label on /tmp myself, so something else is setting it to tmpfs_t in conflict with what selinux-policy and openvpn are expecting...
Comment 5 Joachim Frieben 2015-12-05 18:21:33 EST
Description of problem:
I tried to activate a VPN connection by means of NetworkManager-openvpn.

Version-Release number of selected component:
selinux-policy-3.13.1-161.fc24.noarch

Additional info:
reporter:       libreport-2.6.3
hashmarkername: setroubleshoot
kernel:         4.4.0-0.rc3.git4.1.fc24.x86_64
type:           libreport
Comment 6 Lukas Vrabec 2015-12-07 05:08:15 EST
*** Bug 1288773 has been marked as a duplicate of this bug. ***
Comment 7 Lukas Vrabec 2015-12-07 06:23:18 EST
*** Bug 1288775 has been marked as a duplicate of this bug. ***
Comment 8 Lukas Vrabec 2015-12-07 12:11:19 EST
*** Bug 1288777 has been marked as a duplicate of this bug. ***
Comment 9 Miroslav Grepl 2015-12-07 17:22:20 EST
In Fedora 23 we have

v /tmp 1777 root root 10d

but we have

q /tmp 1777 root root 10d

in rawhide as a part of "/usr/lib/tmpfiles.d/tmp.conf" which causes this issue.
Comment 10 Lukas Vrabec 2015-12-08 08:19:22 EST
Hi systemd folks!

If you check: systemd/src/tmpfiles/tmpfiles.c:
1280                 if (IN_SET(i->type, CREATE_SUBVOLUME_NEW_QUOTA, CREATE_SUBVOLUME_INHERIT_QUOTA)) {
1281                         r = btrfs_subvol_auto_qgroup(i->path, 0, i->type == CREATE_SUBVOLUME_NEW_QUOTA);

Function btrfs_subvol_auto_qgroup calls btrfs_subvol_auto_qgroup_fd and in this function is calling: btrfs_qgroup_create(fd, new_qgroupid) and  btrfs_qgroupid_make(lowest - 1, subvol_id, &new_qgroupid). 


When option 'v' is set btrfs_subvol_make() is used instead of btrfs_qgroupid_make.


I believe issue is somewhere in btrfs_qgroupid_make, probably it's needed to set right context in this function. 

Could someone look at it? 

Thank you.
Comment 11 Miroslav Grepl 2015-12-20 06:15:00 EST
Opened

https://github.com/systemd/systemd/issues/2196

github issue.

Thank you.
Comment 12 Paul Moore 2016-01-04 19:02:53 EST
I just took a quick look at this on my current (as of January 4, 2016) Rawhide system, and I'm seeing /tmp mounted as a tmpfs filesystem as well.  Looking at the tmpfiles.d(5) manpage, I suspect this is due to the fact that I am not using btrfs, but rather ext4; if I were using btrfs I would expect /tmp to be a btrfs subvolume (which would likely have its own problems).  Since my /tmp directory is a tmpfs filesystem, this tends to mess everything up as the labels and file transitions are setup for tmp_t and not tmpfs_t.

Is tmpfiles.d new?  Did it change the filesystem used for /tmp recently?  Looking at the manpage, it doesn't look like only changing from 'v' to 'q' would have the effect we are seeing?
Comment 13 Adam Williamson 2016-01-04 19:04:14 EST
/tmp has been a tmpfs by default for several releases.
Comment 14 Paul Moore 2016-01-04 19:14:36 EST
Miroslav, has the policy changed with respect to tmp_t and tmpfs_t recently?
Comment 15 Miroslav Grepl 2016-01-05 07:52:45 EST
(In reply to Paul Moore from comment #14)
> Miroslav, has the policy changed with respect to tmp_t and tmpfs_t recently?

There are no recent changes in the policy. See my comment #9 where it works with 

v /tmp 1777 root root 10d

even /tmp is mounted as a tmpfs filesystem.

For me it looks like we need to fix labeling in systemd as we do it for another mount points.
Comment 16 Paul Moore 2016-01-05 14:18:51 EST
Okay, sounds like it is a systemd problem then ... it is puzzling as to why they would handle the labeling differently; I suspect it has to do with some btrfs quirk, but I haven't looked.
Comment 17 Paul Moore 2016-01-08 13:25:24 EST
*** Bug 1287005 has been marked as a duplicate of this bug. ***
Comment 18 Paul Moore 2016-01-08 13:28:25 EST
Now that we know the underlying cause and are seeing this affecting more than just openvpn, I'm updating the subject line.
Comment 19 Giulio 'juliuxpigface' 2016-01-21 17:02:47 EST
Description of problem:
I encountered this after the boot of a Cinnamon Live session (Rawhide 20160121 Cinnamon Spin)

Version-Release number of selected component:
selinux-policy-3.13.1-168.fc24.noarch

Additional info:
reporter:       libreport-2.6.3
hashmarkername: setroubleshoot
kernel:         4.5.0-0.rc0.git7.1.fc24.x86_64
type:           libreport
Comment 20 Vít Ondruch 2016-02-03 08:34:15 EST
Any chance to get this into Fedora?

https://github.com/systemd/systemd/pull/2507
Comment 21 Giulio 'juliuxpigface' 2016-02-03 16:32:54 EST
Description of problem:
I encounter this frequently; at least on every boot, but I've also seen it later too.

This might the same issue as bug 1296150

Version-Release number of selected component:
selinux-policy-3.13.1-168.fc24.noarch

Additional info:
reporter:       libreport-2.6.3
hashmarkername: setroubleshoot
kernel:         4.5.0-0.rc1.git2.1.fc24.x86_64
type:           libreport
Comment 22 Jan Kurik 2016-02-24 10:46:38 EST
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase

Note You need to log in before you can comment on or make changes to this bug.