Description of problem: SELinux is preventing unix_chkpwd from 'map' accesses on the file /etc/ld.so.cache. ***** Plugin restorecon (94.8 confidence) suggests ************************ If you want to fix the label. /etc/ld.so.cache default label should be ld_so_cache_t. Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent directory in which case try to change the following command accordingly. Do # /sbin/restorecon -v /etc/ld.so.cache ***** Plugin catchall_labels (5.21 confidence) suggests ******************* If you want to allow unix_chkpwd to have map access on the ld.so.cache file Then you need to change the label on /etc/ld.so.cache Do # semanage fcontext -a -t FILE_TYPE '/etc/ld.so.cache' where FILE_TYPE is one of the following: chkpwd_exec_t, file_context_t, fonts_cache_t, fonts_t, ld_so_cache_t, ld_so_t, lib_t, locale_t, prelink_exec_t, shadow_t, sssd_public_t, system_db_t, textrel_shlib_t. Then execute: restorecon -v '/etc/ld.so.cache' ***** Plugin catchall (1.44 confidence) suggests ************************** If you believe that unix_chkpwd should be allowed map access on the ld.so.cache file 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: # ausearch -c 'unix_chkpwd' --raw | audit2allow -M my-unixchkpwd # semodule -X 300 -i my-unixchkpwd.pp Additional Information: Source Context system_u:system_r:chkpwd_t:s0-s0:c0.c1023 Target Context system_u:object_r:etc_t:s0 Target Objects /etc/ld.so.cache [ file ] Source unix_chkpwd Source Path unix_chkpwd Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages glibc-2.26-24.fc27.x86_64 glibc-2.26-24.fc27.i686 Policy RPM selinux-policy-3.13.1-283.24.fc27.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 4.14.16-300.fc27.x86_64 #1 SMP Wed Jan 31 19:24:27 UTC 2018 x86_64 x86_64 Alert Count 2 First Seen 2018-02-08 02:17:48 IST Last Seen 2018-02-08 02:17:48 IST Local ID 0b438130-d167-4653-9c10-2845c9be19b2 Raw Audit Messages type=AVC msg=audit(1518036468.497:203): avc: denied { map } for pid=1576 comm="unix_chkpwd" path="/etc/ld.so.cache" dev="dm-0" ino=919788 scontext=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0 Hash: unix_chkpwd,chkpwd_t,etc_t,file,map Version-Release number of selected component: selinux-policy-3.13.1-283.24.fc27.noarch Additional info: component: selinux-policy reporter: libreport-2.9.3 hashmarkername: setroubleshoot kernel: 4.14.16-300.fc27.x86_64 type: libreport
Hi, Is there any new way how /etc/ld.so.cache created? Thanks, Lukas.
(In reply to Lukas Vrabec from comment #1) > Is there any new way how /etc/ld.so.cache created? No, we didn't change anything in Fedora 27. It could be the old sln/ldconfig hardlink issue. ldconfig might have been running with the sln label instead.
I got 6 errors like this. After updating Fedora
I can confirm this error that came up just 1-2 days ago on both of my F27 computers, with daily updates. Maybe similar to Bug 1513806, https://bugzilla.redhat.com/show_bug.cgi?id=1513806?
I can confirm this started immediately after the update to the new selinux policy, selinux-policy-3.13.1-283.26.fc27.noarch, a few days ago. Here are the details of one of 13 repeated alerts: [root@chainsaw ~]# sealert -l 8119fd36-0aed-4495-83dd-47c8efc9d379 SELinux is preventing systemd-tmpfile from map access on the file /etc/ld.so.cache. ***** Plugin restorecon (94.8 confidence) suggests ************************ If you want to fix the label. /etc/ld.so.cache default label should be ld_so_cache_t. Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent directory in which case try to change the following command accordingly. Do # /sbin/restorecon -v /etc/ld.so.cache ***** Plugin catchall_labels (5.21 confidence) suggests ******************* If you want to allow systemd-tmpfile to have map access on the ld.so.cache file Then you need to change the label on /etc/ld.so.cache Do # semanage fcontext -a -t FILE_TYPE '/etc/ld.so.cache' where FILE_TYPE is one of the following: file_context_t, fonts_cache_t, fonts_t, ld_so_cache_t, ld_so_t, lib_t, locale_t, prelink_exec_t, rpm_var_lib_t, sssd_public_t, systemd_tmpfiles_exec_t, textrel_shlib_t. Then execute: restorecon -v '/etc/ld.so.cache' ***** Plugin catchall (1.44 confidence) suggests ************************** If you believe that systemd-tmpfile should be allowed map access on the ld.so.cache file 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: # ausearch -c 'systemd-tmpfile' --raw | audit2allow -M my-systemdtmpfile # semodule -X 300 -i my-systemdtmpfile.pp Additional Information: Source Context system_u:system_r:systemd_tmpfiles_t:s0 Target Context system_u:object_r:etc_t:s0 Target Objects /etc/ld.so.cache [ file ] Source systemd-tmpfile Source Path systemd-tmpfile Port <Unknown> Host chainsaw.msnomer.com Source RPM Packages Target RPM Packages glibc-2.26-26.fc27.x86_64 Policy RPM selinux-policy-3.13.1-283.26.fc27.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name chainsaw.msnomer.com Platform Linux chainsaw.msnomer.com 4.15.6-300.fc27.x86_64 #1 SMP Mon Feb 26 18:43:03 UTC 2018 x86_64 x86_64 Alert Count 2 First Seen 2018-03-07 09:11:21 EST Last Seen 2018-03-08 09:28:12 EST Local ID 8119fd36-0aed-4495-83dd-47c8efc9d379 Raw Audit Messages type=AVC msg=audit(1520519292.693:311): avc: denied { map } for pid=16955 comm="systemd-tmpfile" path="/etc/ld.so.cache" dev="dm-0" ino=133257 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0 Hash: systemd-tmpfile,systemd_tmpfiles_t,etc_t,file,map And here are some other alerts: Mar 08 09:12:59 chainsaw.msnomer.com setroubleshoot[1121]: SELinux is preventing rngd from map access on the file /etc/ld.so.cache. For complete SELinux messages run: sealert -l 701ff475-42db-40dc-9bdd-316b1ca18ad3 Mar 08 09:13:06 chainsaw.msnomer.com setroubleshoot[1121]: SELinux is preventing gssproxy from map access on the file /etc/ld.so.cache. For complete SELinux messages run: sealert -l aeeff2c0-e8f9-4302-b9a0-b8dfe57e5754 Mar 08 09:13:06 chainsaw.msnomer.com setroubleshoot[1121]: SELinux is preventing (uetoothd) from mounton access on the directory /var/lib/bluetooth. For complete SELinux messages run: sealert -l 7be5e036-3427-4010-bd45-205b01063ade Mar 08 09:13:11 chainsaw.msnomer.com setroubleshoot[1121]: SELinux is preventing rtkit-daemon from map access on the file /etc/ld.so.cache. For complete SELinux messages run: sealert -l 3c132977-a9f8-4938-8967-c31ebd4941b8 Mar 08 09:13:17 chainsaw.msnomer.com setroubleshoot[1121]: SELinux is preventing systemd-hostnam from map access on the file /etc/ld.so.cache. For complete SELinux messages run: sealert -l 3b6e28d5-60ce-410b-a2d2-c4923d509ada Mar 08 09:13:22 chainsaw.msnomer.com setroubleshoot[1121]: SELinux is preventing systemd-logind from map access on the file /etc/ld.so.cache. For complete SELinux messages run: sealert -l 2da5ad76-1230-4206-83ac-123a90f2388b Mar 08 09:17:54 chainsaw.msnomer.com setroubleshoot[2697]: SELinux is preventing unix_chkpwd from map access on the file /etc/ld.so.cache. For complete SELinux messages run: sealert -l c609650f-a85e-44d3-b6a0-5d9a2d1a423c Mar 08 09:24:51 chainsaw.msnomer.com setroubleshoot[16929]: SELinux is preventing unix_chkpwd from map access on the file /etc/ld.so.cache. For complete SELinux messages run: sealert -l c609650f-a85e-44d3-b6a0-5d9a2d1a423c Mar 08 09:25:04 chainsaw.msnomer.com setroubleshoot[16944]: org.freedesktop.DBus.Error.AccessDenied: Connection ":1.106" is not allowed to own the service "org.fedoraproject.Setroubleshootd" due to security policies in the configuration file Mar 08 09:28:21 chainsaw.msnomer.com setroubleshoot[16959]: SELinux is preventing systemd-tmpfile from map access on the file /etc/ld.so.cache. For complete SELinux messages run: sealert -l 8119fd36-0aed-4495-83dd-47c8efc9d379
Description of problem: de repente aparecieron estas notificaciones de errores en el sistema Version-Release number of selected component: selinux-policy-3.13.1-283.26.fc27.noarch Additional info: reporter: libreport-2.9.3 hashmarkername: setroubleshoot kernel: 4.15.6-300.fc27.x86_64 type: libreport
I have a similar problem, I think it's the same issue: SELinux is preventing systemd-tmpfile from map access on the file /etc/ld.so.cache. ***** Plugin restorecon (94.8 confidence) suggests ************************ If you want to fix the label. /etc/ld.so.cache default label should be ld_so_cache_t. Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent directory in which case try to change the following command accordingly. Do # /sbin/restorecon -v /etc/ld.so.cache ***** Plugin catchall_labels (5.21 confidence) suggests ******************* If you want to allow systemd-tmpfile to have map access on the ld.so.cache file Then you need to change the label on /etc/ld.so.cache Do # semanage fcontext -a -t FILE_TYPE '/etc/ld.so.cache' where FILE_TYPE is one of the following: file_context_t, fonts_cache_t, fonts_t, ld_so_cache_t, ld_so_t, lib_t, locale_t, prelink_exec_t, rpm_var_lib_t, sssd_public_t, systemd_tmpfiles_exec_t, textrel_ Then execute: restorecon -v '/etc/ld.so.cache' ***** Plugin catchall (1.44 confidence) suggests ************************** If you believe that systemd-tmpfile should be allowed map access on the ld.so.cache file 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: # ausearch -c 'systemd-tmpfile' --raw | audit2allow -M my-systemdtmpfile # semodule -X 300 -i my-systemdtmpfile.pp
There isn't any information that others haven't already provided, so I'm just here to say I am also seeing the same issue since the last round of updates.
*** Bug 1543739 has been marked as a duplicate of this bug. ***
*** Bug 1542933 has been marked as a duplicate of this bug. ***
Hi all, We need to know which process creating /etc/ld.so.cache to create proper file transition SELinux rules. Any idea?
(In reply to Lukas Vrabec from comment #11) > Hi all, > > We need to know which process creating /etc/ld.so.cache to create proper > file transition SELinux rules. Any idea? I believe ldconfig creates the cache: LDCONFIG(8) Linux Programmer's Manual LDCONFIG(8) NAME ldconfig - configure dynamic linker run-time bindings SYNOPSIS /sbin/ldconfig [-nNvXV] [-f conf] [-C cache] [-r root] directory... /sbin/ldconfig -l [-v] library... /sbin/ldconfig -p DESCRIPTION ldconfig creates the necessary links and cache to the most recent shared libraries found in the directories specified on the command line, in the file /etc/ld.so.conf, and in the trusted directories, /lib and /usr/lib (on some 64-bit architectures such as x86-64, lib and /usr/lib are the trusted directories for 32-bit libraries, while /lib64 and /usr/lib64 are used for 64-bit libraries).
Description of problem: SELinux alerts occuring after Fedora update. I have not made any manual changes to /etc/ld.so.cache before seeing these alerts; they seem to have arisen spontaneously after the update. I have now manually ran restorecon to fix the alert as instructed by the assistant. Version-Release number of selected component: selinux-policy-3.13.1-283.26.fc27.noarch Additional info: reporter: libreport-2.9.3 hashmarkername: setroubleshoot kernel: 4.15.7-300.fc27.x86_64 type: libreport
(In reply to Thomas Wright from comment #13) > Description of problem: > SELinux alerts occuring after Fedora update. I have not made any manual > changes to /etc/ld.so.cache before seeing these alerts; they seem to have > arisen spontaneously after the update. I have now manually ran restorecon to > fix the alert as instructed by the assistant. What's the label on /sbin/ldconfig? Could you show us the output of: ls -lZ /sbin/ldconfig (See comment 2.)
(In reply to Florian Weimer from comment #14) > (In reply to Thomas Wright from comment #13) > > Description of problem: > > SELinux alerts occuring after Fedora update. I have not made any manual > > changes to /etc/ld.so.cache before seeing these alerts; they seem to have > > arisen spontaneously after the update. I have now manually ran restorecon to > > fix the alert as instructed by the assistant. > > What's the label on /sbin/ldconfig? Could you show us the output of: > > ls -lZ /sbin/ldconfig > > (See comment 2.) [tony@chainsaw ~]$ ls -laZ /sbin/ldconfig -rwxr-xr-x. 2 root root system_u:object_r:ldconfig_exec_t:s0 1036040 Mar 1 07:01 /sbin/ldconfig [tony@chainsaw ~]$
(In reply to Tony from comment #15) > (In reply to Florian Weimer from comment #14) > > (In reply to Thomas Wright from comment #13) > > > Description of problem: > > > SELinux alerts occuring after Fedora update. I have not made any manual > > > changes to /etc/ld.so.cache before seeing these alerts; they seem to have > > > arisen spontaneously after the update. I have now manually ran restorecon to > > > fix the alert as instructed by the assistant. > > > > What's the label on /sbin/ldconfig? Could you show us the output of: > > > > ls -lZ /sbin/ldconfig > > > > (See comment 2.) > > [tony@chainsaw ~]$ ls -laZ /sbin/ldconfig > -rwxr-xr-x. 2 root root system_u:object_r:ldconfig_exec_t:s0 1036040 Mar 1 > 07:01 /sbin/ldconfig That's the right label, but it's possible that when ldconfig ran last, it had the wrong label. Hard to tell, I think, but I'm not an SELinux expert at all.
*** Bug 1554513 has been marked as a duplicate of this bug. ***
*** Bug 1554515 has been marked as a duplicate of this bug. ***
*** Bug 1554549 has been marked as a duplicate of this bug. ***
Description of problem: I udated my system and after I did, I began receiving errors stating that their was an error. Version-Release number of selected component: selinux-policy-3.13.1-283.26.fc27.noarch Additional info: reporter: libreport-2.9.3 hashmarkername: setroubleshoot kernel: 4.15.7-300.fc27.x86_64 type: libreport
This stopped happening. Last updates: Transaction performed with: Installed dnf-2.7.5-2.fc27.noarch @updates Installed rpm-4.14.1-1.fc27.x86_64 @updates Packages Altered: Install libmicrodns-0.0.8-1.fc27.x86_64 @updates Install libplacebo-0.4.0-1.fc27.x86_64 @updates Install mesa-vulkan-drivers-17.3.6-1.fc27.x86_64 @updates Install spirv-tools-libs-2018.1-0.2.20180205.git9e19fc0.fc27.x86_64 @updates Upgraded vlc-3.0.0-1.fc27.x86_64 @rpmfusion-free-updates Upgrade 3.0.1-1.fc27.x86_64 @rpmfusion-free-updates Upgraded vlc-core-3.0.0-1.fc27.x86_64 @rpmfusion-free-updates Upgrade 3.0.1-1.fc27.x86_64 @rpmfusion-free-updates Install vulkan-1.0.68.0-2.fc27.x86_64 @updates Install vulkan-filesystem-1.0.68.0-2.fc27.noarch @updates Scriptlet output: 1 Running as unit: run-r0543c13325d5401bad9a0aa80b5f7eec.service 2 Running as unit: run-r1547f5706d7142fb865708dc4d0a2baa.service [root@chainsaw ~]#
*** Bug 1558383 has been marked as a duplicate of this bug. ***
*** Bug 1482355 has been marked as a duplicate of this bug. ***
*** Bug 1559230 has been marked as a duplicate of this bug. ***
*** Bug 1554396 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 1513806 ***