Bug 1513806 - Improper SELinux domain on /etc/ld.so.cache after reboot (should be ld_so_cache_t but is etc_t)
Summary: Improper SELinux domain on /etc/ld.so.cache after reboot (should be ld_so_cac...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 27
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Lukas Vrabec
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1541795 1543153 1553422 1553637 1553820 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-16 01:56 UTC by Michael D. Parker
Modified: 2018-05-07 16:02 UTC (History)
28 users (show)

Fixed In Version: selinux-policy-3.13.1-283.34.fc27
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-05-05 22:27:06 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Michael D. Parker 2017-11-16 01:56:40 UTC
Description of problem:
Apparently when ld.so.cache is rebuilt, the SELinux label set is not correct.  However interestingly doing a restorecon on the file will return the proper label.


Version-Release number of selected component (if applicable):
Fedora 27 patched and updated as of report date/time.
Unfortunately at this point I have been unable to trace the right module doing this.

How reproducible:
VERY!


Steps to Reproduce:
1. rm /etc/ld.so.cache;/sbin/ldconfig -X
2. ls -lZ show that file in ld_so_cache_t SELinux domain
3. reboot
4. once system comes up do ls -lZ /etc/ld.so.cache and notice the the file has apparently been rebuilt and now has the SELinux domain etc_t
5. I note that running restorecon -v /etc/ld.so.cache restores the proper domain but this is FAR too late for many of the startup programs that attempt to use this file.

Actual results:


Expected results:
The /etc/ld.so.cache should never have its type domain changed.  This causes numerous AVC errors from many other resources.

Additional info:

Comment 1 Michael D. Parker 2017-11-16 01:58:23 UTC
I run in enforcing mode so I am not sure what type of difficulties that are being caused by the denial of access to /etc/ld.so.cache during the bootup process.

Comment 2 Louis-P L Perreault 2017-12-12 18:25:20 UTC
Same thing here (fresh Fedora 27 install on VirtualBox). The SELinux domain gets reset to etc_t at each system reboot.

# ls -Z /etc/ld.so.cache 
system_u:object_r:etc_t:s0 /etc/ld.so.cache

# /sbin/restorecon -v /etc/ld.so.cache
Relabeled /etc/ld.so.cache from system_u:object_r:etc_t:s0 to system_u:object_r:ld_so_cache_t:s0

# ls -Z /etc/ld.so.cache 
system_u:object_r:ld_so_cache_t:s0 /etc/ld.so.cache

Here is the system information.

# uname -r
4.14.3-300.fc27.x86_64

# rpm -qa | grep selinux
rpm-plugin-selinux-4.14.0-2.fc27.x86_64
libselinux-python3-2.7-2.fc27.x86_64
libselinux-2.7-2.fc27.x86_64
selinux-policy-targeted-3.13.1-283.17.fc27.noarch
selinux-policy-3.13.1-283.17.fc27.noarch
libselinux-utils-2.7-2.fc27.x86_64

Comment 3 J.D. 2017-12-25 08:34:42 UTC
This bug only occurs if the VirtualBox guest additions are installed.

ld.so.cache is not regenerated, except if it's deleted, at boot without the guest additions installed.

ld.so.cache is regenerated at boot (according to the last modified time) with the wrong label (etc_t) when the guest additions are installed.

The file size and checksum of ld.so.cache remain identical with and without the guest additions installed. I don't know why this file would be modified if it stays the same.

tested on VirtualBox 5.2.4

Comment 4 Zbigniew Jędrzejewski-Szmek 2017-12-26 16:19:20 UTC
This is fairly easy to recreate without rebooting:
$ sudo rm /etc/ld.so.cache && sudo ldconfig -X
ls -lZ /etc/ld.so.cache
$ -rw-r--r--. 1 root root unconfined_u:object_r:ld_so_cache_t:s0 308225 Dec 26 17:00 /etc/ld.so.cache
$ sudo rm /etc/ld.so.cache && sudo systemctl restart ldconfig.service
$ ls -lZ /etc/ld.so.cache
-rw-r--r--. 1 root root system_u:object_r:etc_t:s0 308225 Dec 26 17:02 /etc/ld.so.cache
$ systemctl cat ldconfig.service|grep Exec
ExecStart=/sbin/ldconfig -X

It seems the file is labelled correctly when the process that creates it is running as unconfined, but incorrectly when the process that creates it is running as system_u. This is on F26, no virtualbox additions installed.

--

Oh, this seems to be fixed with updated selinux-policy.
selinux-policy-3.13.1-260.14.fc26.noarch → reproducible
selinux-policy-3.13.1-260.17.fc26.noarch → nonreproducible

I'll close this. Please reopen if the issue still occurs.

Comment 5 raztus 2018-01-24 18:40:11 UTC
I am still experiencing this with Virtualbox Guest Additions 5.2.6 and selinux-policy-3.13.1-283.21.fc27.src.rpm

I can confirm that following the previous steps without a reboot leaves the correct label:

$ sudo rm /etc/ld.so.cache && sudo ldconfig -X
$ ls -lZ /etc/ld.so.cache 
-rw-r--r--. 1 root root unconfined_u:object_r:ld_so_cache_t:s0 66230 Jan 24 10:32 /etc/ld.so.cache
$ sudo rm /etc/ld.so.cache && sudo systemctl restart ldconfig.service
$ ls -lZ /etc/ld.so.cache 
-rw-r--r--. 1 root root system_u:object_r:ld_so_cache_t:s0 66230 Jan 24 10:33 /etc/ld.so.cache

However, after a reboot the label is reset:

-rw-r--r--. 1 root root system_u:object_r:etc_t:s0 66230 Jan 24 10:38 /etc/ld.so.cache

I can also confirm that this only occurs with Virtualbox Guest Additions installed. Is this a Virtualbox bug at this point?

Comment 6 Michael D. Parker 2018-01-24 18:49:41 UTC
This is STILL a problem...and it is NOT connected with Virtualbox Guest Additions.

This still happens on a currently patched Fedora 27 system:

Extract of AVC error log:

Jan 23 11:52:44 fedora27 audit[1005]: AVC avc:  denied  { map } for  pid=1005 comm="hostname" path="/etc/ld.so.cache" dev="dm-0" ino=16777336 scontext=system_u:system_r:hostname_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=1
Jan 23 11:52:59 fedora27 audit[1087]: AVC avc:  denied  { map } for  pid=1087 comm="unix_chkpwd" path="/etc/ld.so.cache" dev="dm-0" ino=16777336 scontext=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=1
Jan 23 11:52:59 fedora27 audit[689]: AVC avc:  denied  { map } for  pid=689 comm="systemd-logind" path="/etc/ld.so.cache" dev="dm-0" ino=16777336 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=1
Jan 23 11:52:59 fedora27 audit[1089]: AVC avc:  denied  { map } for  pid=1089 comm="unix_chkpwd" path="/etc/ld.so.cache" dev="dm-0" ino=16777336 scontext=system_u:system_r:chkpwd_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=1
Jan 23 12:08:04 fedora27 audit[1196]: AVC avc:  denied  { map } for  pid=1196 comm="systemd-tmpfile" path="/etc/ld.so.cache" dev="dm-0" ino=16777336 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=1
Jan 23 15:52:38 fedora27 audit[1346]: AVC avc:  denied  { map } for  pid=1346 comm="unix_chkpwd" path="/etc/ld.so.cache" dev="dm-0" ino=16777336 scontext=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=1
Jan 23 15:52:38 fedora27 audit[1348]: AVC avc:  denied  { map } for  pid=1348 comm="unix_chkpwd" path="/etc/ld.so.cache" dev="dm-0" ino=16777336 scontext=system_u:system_r:chkpwd_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=1
Jan 23 21:48:49 fedora27 audit[1636]: AVC avc:  denied  { map } for  pid=1636 comm="hostname" path="/etc/ld.so.cache" dev="dm-0" ino=16777336 scontext=system_u:system_r:hostname_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=1
Jan 24 09:46:56 fedora27 audit[2188]: AVC avc:  denied  { map } for  pid=2188 comm="hostname" path="/etc/ld.so.cache" dev="dm-0" ino=16777336 scontext=system_u:system_r:hostname_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=1

Comment 7 Michael D. Parker 2018-01-24 18:52:35 UTC
Package and versions for selinux:


libselinux-utils-2.7-3.fc27.x86_64
selinux-policy-3.13.1-283.21.fc27.noarch
selinux-policy-mls-3.13.1-283.21.fc27.noarch
libselinux-devel-2.7-3.fc27.x86_64
libselinux-2.7-3.fc27.x86_64
selinux-policy-targeted-3.13.1-283.21.fc27.noarch
selinux-policy-minimum-3.13.1-283.21.fc27.noarch
libselinux-static-2.7-3.fc27.x86_64
selinux-policy-devel-3.13.1-283.21.fc27.noarch
rpm-plugin-selinux-4.14.0-2.fc27.x86_64
libselinux-python-2.7-3.fc27.x86_64
selinux-policy-sandbox-3.13.1-283.21.fc27.noarch
selinux-policy-doc-3.13.1-283.21.fc27.noarch

Comment 8 Michael D. Parker 2018-01-24 19:03:09 UTC
Re-closing.  

I'm embarrassed to say this but I although I thought NO Virtualbox guest additions had been installed.  I was misinformed there was a OLD version there but it was not in the RPM package manifest that I could determine.

Looking further, I found the critter hiding in /opt/VBoxGuestAdditions-<version>

Please accept my thanks and appologies.

Comment 9 Scott Worley 2018-03-07 14:40:35 UTC
Hi,
This came back after an update last night (2018-03-06) of F27. I believe an SElinux package was one of the 4 or 5 that were updated. Since the update on every reboot I'm getting SElinux alerts on ld.so.cache label.

SELinux is preventing hostname 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 hostname 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: fonts_cache_t, fonts_t, hostname_exec_t, ld_so_cache_t, ld_so_t, lib_t, locale_t, prelink_exec_t, textrel_shlib_t.
Then execute:
restorecon -v '/etc/ld.so.cache'


*****  Plugin catchall (1.44 confidence) suggests   **************************

If you believe that hostname 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 'hostname' --raw | audit2allow -M my-hostname
# semodule -X 300 -i my-hostname.pp

Additional Information:
Source Context                system_u:system_r:hostname_t:s0
Target Context                system_u:object_r:etc_t:s0
Target Objects                /etc/ld.so.cache [ file ]
Source                        hostname
Source Path                   hostname
Port                          <Unknown>
Host                          localhost.localdomain
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                     new-host-2
Platform                      Linux new-host-2 4.15.6-300.fc27.x86_64 #1 SMP Mon
                              Feb 26 18:43:03 UTC 2018 x86_64 x86_64
Alert Count                   7
First Seen                    2018-03-06 21:11:34 EST
Last Seen                     2018-03-07 09:22:32 EST
Local ID                      c46f4b8b-6376-4d6c-a67f-0d3d9222a211

Raw Audit Messages
type=AVC msg=audit(1520432552.367:351): avc:  denied  { map } for  pid=3966 comm="hostname" path="/etc/ld.so.cache" dev="dm-0" ino=201326834 scontext=system_u:system_r:hostname_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0


Hash: hostname,hostname_t,etc_t,file,map

Comment 10 krinkodot22 2018-03-08 03:46:52 UTC
Same here. Below are some alerts I got today, after having installed system updates last night:

--------------------------------

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                          lappierfedora
Source RPM Packages           
Target RPM Packages           glibc-2.26-26.fc27.x86_64 glibc-2.26-26.fc27.i686
Policy RPM                    selinux-policy-3.13.1-283.26.fc27.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     lappierfedora
Platform                      Linux lappierfedora 4.15.6-300.fc27.x86_64 #1 SMP
                              Mon Feb 26 18:43:03 UTC 2018 x86_64 x86_64
Alert Count                   1
First Seen                    2018-03-07 20:52:56 EST
Last Seen                     2018-03-07 20:52:56 EST
Local ID                      a02d305e-6f57-465d-83bb-b227ffa7c654

Raw Audit Messages
type=AVC msg=audit(1520473976.77:271): avc:  denied  { map } for  pid=3491 comm="systemd-tmpfile" path="/etc/ld.so.cache" dev="dm-0" ino=808212 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

--------------------------------

SELinux is preventing systemd-hostnam 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-hostnam 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, sssd_public_t, systemd_hostnamed_exec_t, textrel_shlib_t.
Then execute:
restorecon -v '/etc/ld.so.cache'


*****  Plugin catchall (1.44 confidence) suggests   **************************

If you believe that systemd-hostnam 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-hostnam' --raw | audit2allow -M my-systemdhostnam
# semodule -X 300 -i my-systemdhostnam.pp

Additional Information:
Source Context                system_u:system_r:systemd_hostnamed_t:s0
Target Context                system_u:object_r:etc_t:s0
Target Objects                /etc/ld.so.cache [ file ]
Source                        systemd-hostnam
Source Path                   systemd-hostnam
Port                          <Unknown>
Host                          lappierfedora
Source RPM Packages           
Target RPM Packages           glibc-2.26-26.fc27.x86_64 glibc-2.26-26.fc27.i686
Policy RPM                    selinux-policy-3.13.1-283.26.fc27.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     lappierfedora
Platform                      Linux lappierfedora 4.15.6-300.fc27.x86_64 #1 SMP
                              Mon Feb 26 18:43:03 UTC 2018 x86_64 x86_64
Alert Count                   3
First Seen                    2018-03-07 20:38:04 EST
Last Seen                     2018-03-07 22:22:41 EST
Local ID                      7928caa2-b1ef-445b-b6b3-66deb3f7f3ea

Raw Audit Messages
type=AVC msg=audit(1520479361.198:328): avc:  denied  { map } for  pid=6598 comm="systemd-hostnam" path="/etc/ld.so.cache" dev="dm-0" ino=808212 scontext=system_u:system_r:systemd_hostnamed_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0


Hash: systemd-hostnam,systemd_hostnamed_t,etc_t,file,map

--------------------------------

SELinux is preventing unix_chkpwd 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 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
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                          lappierfedora
Source RPM Packages           
Target RPM Packages           glibc-2.26-26.fc27.x86_64 glibc-2.26-26.fc27.i686
Policy RPM                    selinux-policy-3.13.1-283.26.fc27.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     lappierfedora
Platform                      Linux lappierfedora 4.15.6-300.fc27.x86_64 #1 SMP
                              Mon Feb 26 18:43:03 UTC 2018 x86_64 x86_64
Alert Count                   1
First Seen                    2018-03-07 20:39:26 EST
Last Seen                     2018-03-07 20:39:26 EST
Local ID                      d8a9c43e-7195-4042-9d54-39a6882b92de

Raw Audit Messages
type=AVC msg=audit(1520473166.344:240): avc:  denied  { map } for  pid=1581 comm="unix_chkpwd" path="/etc/ld.so.cache" dev="dm-0" ino=808212 scontext=system_u:system_r:chkpwd_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0


Hash: unix_chkpwd,chkpwd_t,etc_t,file,map

Comment 11 Zbigniew Jędrzejewski-Szmek 2018-03-08 05:31:26 UTC
Reopening. This seems to have come back dependent on the selinux-policy version, while nothing changes in systemd in this regard, so reassigning.

Comment 12 Gergely Gombos 2018-03-08 09:39:34 UTC
I can confirm this error that came up just 1-2 days ago on both of my F27 computers, with daily updates.

Comment 13 Brian neutrino78x 2018-03-11 23:25:54 UTC
I get this on my machine as well. Every time I boot, there are eight SELinux alerts, all for /etc/ld.so.cache.

Brand new Fedora 27 installation, just installed last week.

Comment 14 Lukas Vrabec 2018-03-12 13:21:38 UTC
*** Bug 1553820 has been marked as a duplicate of this bug. ***

Comment 15 Lukas Vrabec 2018-03-12 13:23:47 UTC
*** Bug 1553637 has been marked as a duplicate of this bug. ***

Comment 16 Lukas Vrabec 2018-03-12 13:26:07 UTC
*** Bug 1553422 has been marked as a duplicate of this bug. ***

Comment 17 Lukas Vrabec 2018-03-12 14:57:23 UTC
*** Bug 1541795 has been marked as a duplicate of this bug. ***

Comment 18 Lukas Vrabec 2018-03-24 22:04:43 UTC
*** Bug 1543153 has been marked as a duplicate of this bug. ***

Comment 19 Jeremy Petersen 2018-04-20 20:53:13 UTC
I'm having this same issue on a fully patched F27 system - 8 SEAlerts at boot up, every time. It looks like there has not been any updates in quite some time. What is the status on this issue?

Comment 20 Daniel Walsh 2018-04-28 09:36:07 UTC
Something on the system is creating /etc/ld.so.cache with the wrong label on boot.

My guess is that 

optional_policy(`
	libs_filetrans_named_content(unconfined_domain_type)
')

Would fix this issue.

Lukas can you add this policy.

Comment 21 Lukas Vrabec 2018-04-28 17:37:40 UTC
We could try it. 

Thanks Dan.

Comment 22 Fedora Update System 2018-04-29 13:18:51 UTC
selinux-policy-3.13.1-283.34.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-aa26da1777

Comment 23 Fedora Update System 2018-04-30 14:17:16 UTC
selinux-policy-3.13.1-283.34.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-aa26da1777

Comment 24 bill.zannoni 2018-05-04 10:00:09 UTC
Description of problem:
Every time I boot into Fedora 27 (running as a VirtualBox VM), freshly updated from 26, This issue comes out and is reported by abrt alert.

Version-Release number of selected component:
selinux-policy-3.13.1-283.32.fc27.noarch

Additional info:
reporter:       libreport-2.9.3
hashmarkername: setroubleshoot
kernel:         4.16.5-200.fc27.x86_64
type:           libreport

Comment 25 bill.zannoni 2018-05-05 19:09:00 UTC
Description of problem:
I upgraded Fedora from 26 to 27. It's running in a VirtualBox VM.

Version-Release number of selected component:
selinux-policy-3.13.1-283.32.fc27.noarch

Additional info:
reporter:       libreport-2.9.3
hashmarkername: setroubleshoot
kernel:         4.16.5-200.fc27.x86_64
type:           libreport

Comment 26 Fedora Update System 2018-05-05 22:27:06 UTC
selinux-policy-3.13.1-283.34.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

Comment 27 Robert Van Voorhees 2018-05-07 14:21:08 UTC
Running 

selinux-policy-3.13.1-283.34.fc27.noarch
selinux-policy-targeted-3.13.1-283.34.fc27.noarch

VBoxGuestAdditions-5.2.8

Results still in:

SELinux is preventing unix_chkpwd from map access on the file /etc/ld.so.cache.

Issue is resolved with the fix:

/sbin/restorecon -v /etc/ld.so.cache

Comment 28 Jeremy Petersen 2018-05-07 15:39:57 UTC
The update, followed up with the restorecon command, fixed it for me. No longer getting alerts on reboot now.

Comment 29 Grant Cohoe 2018-05-07 16:01:19 UTC
I see the same behavior as #27 above.

selinux-policy-3.13.1-283.34.fc27.noarch
selinux-policy-targeted-3.13.1-283.34.fc27.noarch

VBox 5.2.8, fresh guest additions install

/etc/ld.so.cache comes up on boot as etc_t. After a restorecon it switches to ld_so_cache_t. Requires manual intervention after each boot.

SELinux alerts for 'attempted access: map' on 'ld.so.cache' by unix_chkpwd and nmbd.


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