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
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
*** Bug 1286239 has been marked as a duplicate of this bug. ***
BTW bug 1287005 seems to be related
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...
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
*** Bug 1288773 has been marked as a duplicate of this bug. ***
*** Bug 1288775 has been marked as a duplicate of this bug. ***
*** Bug 1288777 has been marked as a duplicate of this bug. ***
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.
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.
Opened https://github.com/systemd/systemd/issues/2196 github issue. Thank you.
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?
/tmp has been a tmpfs by default for several releases.
Miroslav, has the policy changed with respect to tmp_t and tmpfs_t recently?
(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.
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.
*** Bug 1287005 has been marked as a duplicate of this bug. ***
Now that we know the underlying cause and are seeing this affecting more than just openvpn, I'm updating the subject line.
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
Any chance to get this into Fedora? https://github.com/systemd/systemd/pull/2507
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
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