Bug 1543153 - SELinux is preventing unix_chkpwd from 'map' accesses on the file /etc/ld.so.cache.
Summary: SELinux is preventing unix_chkpwd from 'map' accesses on the file /etc/ld.so....
Keywords:
Status: CLOSED DUPLICATE of bug 1513806
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 27
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Lukas Vrabec
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:d35be1f05ede9d3395595c531ba...
: 1482355 1542933 1543739 1554396 1554513 1554515 1554549 1558383 1559230 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-02-07 20:54 UTC by Subhadeep Dey
Modified: 2018-03-24 22:04 UTC (History)
37 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-03-24 22:04:43 UTC


Attachments (Terms of Use)

Description Subhadeep Dey 2018-02-07 20:54:04 UTC
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

Comment 1 Lukas Vrabec 2018-02-27 14:45:01 UTC
Hi, 

Is there any new way how /etc/ld.so.cache created? 

Thanks,
Lukas.

Comment 2 Florian Weimer 2018-02-27 14:50:50 UTC
(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.

Comment 3 HDME 2018-03-05 15:40:34 UTC
I got 6 errors like this.
After updating Fedora

Comment 4 Gergely Gombos 2018-03-08 09:41:16 UTC
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?

Comment 5 Tony 2018-03-08 14:36:25 UTC
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

Comment 6 Etzael 2018-03-08 21:50:30 UTC
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

Comment 7 Till Hofmann 2018-03-09 10:13:47 UTC
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

Comment 8 Jake Arkinstall 2018-03-09 12:15:22 UTC
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.

Comment 9 Lukas Vrabec 2018-03-10 14:11:20 UTC
*** Bug 1543739 has been marked as a duplicate of this bug. ***

Comment 10 Lukas Vrabec 2018-03-10 14:26:38 UTC
*** Bug 1542933 has been marked as a duplicate of this bug. ***

Comment 11 Lukas Vrabec 2018-03-10 17:39:40 UTC
Hi all, 

We need to know which process creating /etc/ld.so.cache to create proper file transition SELinux rules. Any idea?

Comment 12 Tony 2018-03-11 14:12:11 UTC
(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).

Comment 13 Thomas Wright 2018-03-12 14:17:51 UTC
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

Comment 14 Florian Weimer 2018-03-12 14:29:30 UTC
(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.)

Comment 15 Tony 2018-03-12 14:40:46 UTC
(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 ~]$

Comment 16 Florian Weimer 2018-03-12 20:17:07 UTC
(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.

Comment 17 Lukas Vrabec 2018-03-13 09:53:25 UTC
*** Bug 1554513 has been marked as a duplicate of this bug. ***

Comment 18 Lukas Vrabec 2018-03-13 09:53:40 UTC
*** Bug 1554515 has been marked as a duplicate of this bug. ***

Comment 19 Lukas Vrabec 2018-03-13 09:54:56 UTC
*** Bug 1554549 has been marked as a duplicate of this bug. ***

Comment 20 Dee C 2018-03-13 15:48:26 UTC
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

Comment 21 Tony 2018-03-13 23:39:48 UTC
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 ~]#

Comment 22 Lukas Vrabec 2018-03-23 13:28:23 UTC
*** Bug 1558383 has been marked as a duplicate of this bug. ***

Comment 23 Lukas Vrabec 2018-03-23 13:30:31 UTC
*** Bug 1482355 has been marked as a duplicate of this bug. ***

Comment 24 Lukas Vrabec 2018-03-24 18:50:24 UTC
*** Bug 1559230 has been marked as a duplicate of this bug. ***

Comment 25 Lukas Vrabec 2018-03-24 18:55:42 UTC
*** Bug 1554396 has been marked as a duplicate of this bug. ***

Comment 26 Lukas Vrabec 2018-03-24 22:04:43 UTC

*** This bug has been marked as a duplicate of bug 1513806 ***


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