Bug 807726 - SELinux is preventing /sbin/ldconfig from 'write' accesses on the file /etc/shells.
Summary: SELinux is preventing /sbin/ldconfig from 'write' accesses on the file /etc/s...
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 16
Hardware: i686
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:d3e26a6b65e02882946023aea97...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-28 15:03 UTC by PackPunk
Modified: 2012-06-11 15:07 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-04-05 20:15:04 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
/var/log/messages from first boot until a few minutes after the error (57.86 KB, text/plain)
2012-03-29 21:42 UTC, Rob Marti
no flags Details

Description PackPunk 2012-03-28 15:03:38 UTC
libreport version: 2.0.8
executable:     /usr/bin/python
hashmarkername: setroubleshoot
kernel:         3.1.0-7.fc16.i686
reason:         SELinux is preventing /sbin/ldconfig from 'write' accesses on the file /etc/shells.
time:           Wed 28 Mar 2012 10:03:14 PM WIT

description:
:SELinux is preventing /sbin/ldconfig from 'write' accesses on the file /etc/shells.
:
:*****  Plugin catchall_labels (71.9 confidence) suggests  ********************
:
:If you want to allow ldconfig to have write access on the shells file
:Then you need to change the label on /etc/shells
:Do
:# semanage fcontext -a -t FILE_TYPE '/etc/shells'
:where FILE_TYPE is one of the following: ldconfig_t, ldconfig_cache_t, user_cron_spool_t, user_tmp_t, rpm_script_tmp_t, afs_cache_t, user_home_t, ld_so_cache_t, puppet_tmp_t, puppet_tmp_t, ldconfig_tmp_t. 
:Then execute: 
:restorecon -v '/etc/shells'
:
:
:*****  Plugin catchall (14.7 confidence) suggests  ***************************
:
:If you believe that ldconfig should be allowed write access on the shells 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:
:# grep ldconfig /var/log/audit/audit.log | audit2allow -M mypol
:# semodule -i mypol.pp
:
:*****  Plugin leaks (14.7 confidence) suggests  ******************************
:
:If you want to ignore ldconfig trying to write access the shells file, because you believe it should not need this access.
:Then you should report this as a bug.  
:You can generate a local policy module to dontaudit this access.
:Do
:# grep /sbin/ldconfig /var/log/audit/audit.log | audit2allow -D -M mypol
:# semodule -i mypol.pp
:
:Additional Information:
:Source Context                unconfined_u:system_r:ldconfig_t:s0-s0:c0.c1023
:Target Context                system_u:object_r:etc_t:s0
:Target Objects                /etc/shells [ file ]
:Source                        ldconfig
:Source Path                   /sbin/ldconfig
:Port                          <Unknown>
:Host                          (removed)
:Source RPM Packages           glibc-2.14.90-24.fc16.6.i686
:Target RPM Packages           setup-2.8.36-3.fc16.noarch
:Policy RPM                    selinux-policy-3.10.0-80.fc16.noarch
:Selinux Enabled               True
:Policy Type                   targeted
:Enforcing Mode                Enforcing
:Host Name                     (removed)
:Platform                      Linux (removed) 3.1.0-7.fc16.i686 #1 SMP Tue Nov 1
:                              21:00:16 UTC 2011 i686 i686
:Alert Count                   1
:First Seen                    Wed 28 Mar 2012 09:56:17 PM WIT
:Last Seen                     Wed 28 Mar 2012 09:56:17 PM WIT
:Local ID                      ede66dfb-87af-46c5-8854-f52eae232935
:
:Raw Audit Messages
:type=AVC msg=audit(1332946577.810:293): avc:  denied  { write } for  pid=14421 comm="ldconfig" path="/etc/shells" dev=sda8 ino=100 scontext=unconfined_u:system_r:ldconfig_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=file
:
:
:type=SYSCALL msg=audit(1332946577.810:293): arch=i386 syscall=execve success=yes exit=0 a0=cb8b7b0 a1=ee82348 a2=bff73b14 a3=bff73b14 items=0 ppid=9518 pid=14421 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=5 comm=ldconfig exe=/sbin/ldconfig subj=unconfined_u:system_r:ldconfig_t:s0-s0:c0.c1023 key=(null)
:
:Hash: ldconfig,ldconfig_t,etc_t,file,write
:
:audit2allow
:
:#============= ldconfig_t ==============
:allow ldconfig_t etc_t:file write;
:
:audit2allow -R
:
:#============= ldconfig_t ==============
:allow ldconfig_t etc_t:file write;
:

Comment 1 Miroslav Grepl 2012-03-29 11:07:40 UTC
This is a leak. Do you know what you were doing when this hapenned.

Comment 2 Rob Marti 2012-03-29 21:40:02 UTC
Essentially a fresh install and yum update of Fedora 16 32bit.  I've attached /var/log/messages from creation until a few minutes after the error - I shut the netbook after the yum install wget that is in the file.

I have a broadcom WNIC so I may have been doing some rmmod/modprobes trying to get it working at the time.

Comment 3 Rob Marti 2012-03-29 21:42:09 UTC
Created attachment 573807 [details]
/var/log/messages from first boot until a few minutes after the error

Comment 4 Daniel Walsh 2012-03-29 21:59:40 UTC
I would bet you that something in first boot leaked it, probally opened something in /etc/shells for write, and then never closed the descriptor.


It will most likely not happen again.

Comment 5 Miroslav Grepl 2012-03-30 06:47:52 UTC
If either you or we see it again, we will reopen the bug. Thank you.

Comment 6 Jonathan S 2012-03-31 15:50:20 UTC
I have the same issue! The "bug" impossible for me to get by, and allways shows up after the same sequence. 

1. Fresh install "Fedora-16-x86_64-Live-Desktop.iso" with sha256=632b2de39033ed1d4a61959c4002e07248793eff828ac5d60edbb7b5dcd7be5c
2. After reboot, started "Software Update" using GUI or terminal "gpk-update-viewer". All 425 updates were DL and installed OK it seemed, immediately therafter the still open "Software Update" app indikated some "cleaning up" aktivities took place lasting about 1 minute. Right at, or after, what seems to be the last update in the long list the error message "GUI popup-message" shows.
3. The popup-warning stated something like 
 SElinux /sbin/idconfig was trying to write to /etc/shell. DENIED ACCESS
The warning message dissapeared without user interaction after about 5 seconds.

- I have tested ISO-file checksum after DL, and also tested ready-made CD. Several disks, several installs, same result.

- I have tested installs with LVM (logical volumes), and also with  "regular partitions", not checking LVM during install ov Debian. Same result.

- Have tested with and withoUt AHCI-mode in BIOS before installing. Same thing and always problem on same place during update.

Please look into this, because I need a stable OS, and I want to leave windows, and Fedora seems to be a more security-concious project than Ubuntu. Am relly hoping for some solution or explanation of how serious this bug is for OS functionality.

Thanks for previous posts.

 

****************************** START FROM MY "LOGFILE" *********************

SELinux is preventing /sbin/ldconfig from write access on the file /etc/shells.

*****  Plugin catchall_labels (71.9 confidence) suggests  ********************

If you want to allow ldconfig to have write access on the shells file
Then you need to change the label on /etc/shells
Do
# semanage fcontext -a -t FILE_TYPE '/etc/shells'
where FILE_TYPE is one of the following: ldconfig_t, ldconfig_cache_t, user_cron_spool_t, user_tmp_t, rpm_script_tmp_t, afs_cache_t, user_home_t, ld_so_cache_t, puppet_tmp_t, puppet_tmp_t, ldconfig_tmp_t. 
Then execute: 
restorecon -v '/etc/shells'


*****  Plugin catchall (14.7 confidence) suggests  ***************************

If you believe that ldconfig should be allowed write access on the shells 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:
# grep ldconfig /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

*****  Plugin leaks (14.7 confidence) suggests  ******************************

If you want to ignore ldconfig trying to write access the shells file, because you believe it should not need this access.
Then you should report this as a bug.  
You can generate a local policy module to dontaudit this access.
Do
# grep /sbin/ldconfig /var/log/audit/audit.log | audit2allow -D -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:ldconfig_t:s0-s0:c0.c1023
Target Context                system_u:object_r:etc_t:s0
Target Objects                /etc/shells [ file ]
Source                        ldconfig
Source Path                   /sbin/ldconfig
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           glibc-2.14.90-24.fc16.6.x86_64
Target RPM Packages           setup-2.8.36-3.fc16.noarch
Policy RPM                    selinux-policy-3.10.0-80.fc16.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux PhenomX4 3.1.0-7.fc16.x86_64 #1 SMP Tue Nov
                              1 21:10:48 UTC 2011 x86_64 x86_64
Alert Count                   1
First Seen                    Sat 31 Mar 2012 03:50:19 PM CEST
Last Seen                     Sat 31 Mar 2012 03:50:19 PM CEST
Local ID                      2f60ddfa-0040-4cdf-a2f9-0b5fce421801

Raw Audit Messages
type=AVC msg=audit(1333201819.96:132): avc:  denied  { write } for  pid=5447 comm="ldconfig" path="/etc/shells" dev=sda3 ino=131625 scontext=system_u:system_r:ldconfig_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=file


type=SYSCALL msg=audit(1333201819.96:132): arch=x86_64 syscall=execve success=yes exit=0 a0=f502e58 a1=f4aa250 a2=7fff3fb292c0 a3=7f57b521b9d0 items=0 ppid=1886 pid=5447 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=ldconfig exe=/sbin/ldconfig subj=system_u:system_r:ldconfig_t:s0-s0:c0.c1023 key=(null)

Hash: ldconfig,ldconfig_t,etc_t,file,write

audit2allow

#============= ldconfig_t ==============
allow ldconfig_t etc_t:file write;

audit2allow -R

#============= ldconfig_t ==============
allow ldconfig_t etc_t:file write;


******************************** END OF MY "LOGFILE" *********************
/end of message

Comment 7 Mark Andrews 2012-04-02 07:59:11 UTC
Like Jonathan I got the same SELinux popup warning after doing a harddisk install from Fedora-16-x86_64-Live-Desktop.iso then applying all available software updates.

Comment 8 Daniel Walsh 2012-04-02 19:15:20 UTC
 cat /etc/shells 

Maybe we can get a clue of the app that added an entry to /etc/shells.

Comment 9 Mark Andrews 2012-04-03 00:40:43 UTC
The only shell which is listed is DASH.

markand@office:~$ cat /media/_Fedora-16-x86_6/etc/shells 
/sbin/nologin
/bin/dash
markand@office:~$

Comment 10 Daniel Walsh 2012-04-05 20:15:04 UTC
Strange, you are going to have other problems without bash being in the list.

cat /etc/shells 
/bin/sh
/bin/bash
/sbin/nologin
/bin/dash


I think it has something to do with bash install.

rpm -q --scripts bash

Shows bash adding its name to /etc/shells.

Add the /bin/sh and /bin/bash line to /etc/shells, and reopen this bug if it happens again.

Comment 11 MarcoP 2012-04-18 23:04:36 UTC
Fresh install, yum update. Then manually added bash ans sh into shells as adviced.

Linux fedora.depot 3.1.0-7.fc16.x86_64 #1 SMP Tue Nov 1 21:10:48 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux


SELinux is preventing /sbin/ldconfig from write access on the file /etc/shells.

*****  Plugin catchall_labels (71.9 confidence) suggests  ********************

If you want to allow ldconfig to have write access on the shells file
Then you need to change the label on /etc/shells
Do
# semanage fcontext -a -t FILE_TYPE '/etc/shells'
where FILE_TYPE is one of the following: ldconfig_t, ldconfig_cache_t, user_cron_spool_t, user_tmp_t, rpm_script_tmp_t, afs_cache_t, user_home_t, ld_so_cache_t, puppet_tmp_t, puppet_tmp_t, ldconfig_tmp_t. 
Then execute: 
restorecon -v '/etc/shells'


*****  Plugin leaks (14.7 confidence) suggests  ******************************

If you want to ignore ldconfig trying to write access the shells file, because you believe it should not need this access.
Then you should report this as a bug.  
You can generate a local policy module to dontaudit this access.
Do
# grep /sbin/ldconfig /var/log/audit/audit.log | audit2allow -D -M mypol
# semodule -i mypol.pp

*****  Plugin catchall (14.7 confidence) suggests  ***************************

If you believe that ldconfig should be allowed write access on the shells 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:
# grep ldconfig /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                unconfined_u:system_r:ldconfig_t:s0-s0:c0.c1023
Target Context                system_u:object_r:etc_t:s0
Target Objects                /etc/shells [ file ]
Source                        ldconfig
Source Path                   /sbin/ldconfig
Port                          <Unknown>
Host                          fedora.depot
Source RPM Packages           glibc-2.14.90-24.fc16.6.x86_64
Target RPM Packages           setup-2.8.36-3.fc16.noarch
Policy RPM                    selinux-policy-3.10.0-80.fc16.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     fedora.depot
Platform                      Linux fedora.depot 3.1.0-7.fc16.x86_64 #1 SMP Tue
                              Nov 1 21:10:48 UTC 2011 x86_64 x86_64
Alert Count                   1
First Seen                    Thu 19 Apr 2012 01:01:31 AM EST
Last Seen                     Thu 19 Apr 2012 01:01:31 AM EST
Local ID                      42d6c56d-b028-4327-950c-15221c9794ce

Raw Audit Messages
type=AVC msg=audit(1334761291.752:238): avc:  denied  { write } for  pid=6132 comm="ldconfig" path="/etc/shells" dev=dm-1 ino=596 scontext=unconfined_u:system_r:ldconfig_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=file


type=SYSCALL msg=audit(1334761291.752:238): arch=x86_64 syscall=execve success=yes exit=0 a0=8e8a538 a1=cebfaa0 a2=7fffe9b5cd78 a3=7f33789919d0 items=0 ppid=1916 pid=6132 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=3 comm=ldconfig exe=/sbin/ldconfig subj=unconfined_u:system_r:ldconfig_t:s0-s0:c0.c1023 key=(null)

Hash: ldconfig,ldconfig_t,etc_t,file,write

audit2allow

#============= ldconfig_t ==============
allow ldconfig_t etc_t:file write;

audit2allow -R

#============= ldconfig_t ==============
allow ldconfig_t etc_t:file write;

Comment 12 Miroslav Grepl 2012-04-20 07:21:15 UTC
Do you install it from LiveCD?

Now you need 

# restorecon -Rv /etc/shells

Comment 13 MarcoP 2012-04-21 08:23:00 UTC
Yes, I installed from LiveCD.

As this is a local-dev machine I disabled selinux.

Thanks.

Comment 14 Miroslav Grepl 2012-04-23 12:47:18 UTC
What LiveCD?

Comment 15 MarcoP 2012-04-23 23:01:37 UTC
Fedora 16 LXDE Spin 64-bit.

Comment 16 Jan Pazdziora 2012-06-11 14:29:14 UTC
(In reply to comment #10)
> Strange, you are going to have other problems without bash being in the list.
> 
> cat /etc/shells 
> /bin/sh
> /bin/bash
> /sbin/nologin
> /bin/dash
> 
> 
> I think it has something to do with bash install.
> 
> rpm -q --scripts bash
> 
> Shows bash adding its name to /etc/shells.
> 
> Add the /bin/sh and /bin/bash line to /etc/shells, and reopen this bug if it
> happens again.

This is bug 752827. If you have bash-4.2.10-4 and upgrade it, it will erase /bin/bash and /bin/sh.

Comment 17 Jan Pazdziora 2012-06-11 15:07:52 UTC
I believe the whole problem is cause by bash. The postuninstall lua scriptlet is missing a close and as noted in bug 752827 comment 30, lua is embedded in rpm and the descriptor is open throughout the whole life of the rpm process. Then the /sbin/ldconfig run from some subsequent package (installed in the same transaction) will inherit it.

Except, I was not able to reproduce this issue on the command line.


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