Bug 745287

Summary: SELinux is preventing /sbin/ldconfig from 'write' accesses on the chr_file /dev/null.
Product: [Fedora] Fedora Reporter: Ankur Sinha (FranciscoD) <sanjay.ankur>
Component: mockAssignee: Clark Williams <williams>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: dominick.grift, dwalsh, mebrown, mgrepl, rc040203, williams
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:e1a74fe02e0f835cc9355f64868a4715e75b5e8e68d6765796f3299c66cc2c85
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-07 18:59:47 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Ankur Sinha (FranciscoD) 2011-10-11 22:33:54 UTC
libreport version: 2.0.6
executable:     /usr/bin/python
hashmarkername: setroubleshoot
kernel:         3.1.0-0.rc9.git0.0.fc16.x86_64
reason:         SELinux is preventing /sbin/ldconfig from 'write' accesses on the chr_file /dev/null.
time:           Wed Oct 12 04:03:53 2011

description:
:SELinux is preventing /sbin/ldconfig from 'write' accesses on the chr_file /dev/null.
:
:*****  Plugin restorecon (98.5 confidence) suggests  *************************
:
:If you want to fix the label. 
:/dev/null default label should be null_device_t.
:Then you can run restorecon.
:Do
:# /sbin/restorecon -v /dev/null
:
:*****  Plugin catchall (1.48 confidence) suggests  ***************************
:
:If you believe that ldconfig should be allowed write access on the null chr_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 (1.48 confidence) suggests  ******************************
:
:If you want to ignore ldconfig trying to write access the null chr_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                unconfined_u:object_r:mock_var_lib_t:s0
:Target Objects                /dev/null [ chr_file ]
:Source                        ldconfig
:Source Path                   /sbin/ldconfig
:Port                          <Unknown>
:Host                          (removed)
:Source RPM Packages           glibc-2.14.90-10
:Target RPM Packages           
:Policy RPM                    selinux-policy-3.10.0-38.fc16
:Selinux Enabled               True
:Policy Type                   targeted
:Enforcing Mode                Enforcing
:Host Name                     (removed)
:Platform                      Linux (removed) 3.1.0-0.rc9.git0.0.fc16.x86_64 #1
:                              SMP Wed Oct 5 15:30:54 UTC 2011 x86_64 x86_64
:Alert Count                   3
:First Seen                    Wed 12 Oct 2011 04:03:26 AM IST
:Last Seen                     Wed 12 Oct 2011 04:03:36 AM IST
:Local ID                      a4fc62cf-20e0-43d1-8854-070399709d53
:
:Raw Audit Messages
:type=AVC msg=audit(1318372416.333:130): avc:  denied  { write } for  pid=12445 comm="ldconfig" path="/dev/null" dev=sda6 ino=1197701 scontext=unconfined_u:system_r:ldconfig_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mock_var_lib_t:s0 tclass=chr_file
:
:
:type=AVC msg=audit(1318372416.333:130): avc:  denied  { write } for  pid=12445 comm="ldconfig" path="/dev/null" dev=sda6 ino=1197701 scontext=unconfined_u:system_r:ldconfig_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mock_var_lib_t:s0 tclass=chr_file
:
:
:type=SYSCALL msg=audit(1318372416.333:130): arch=x86_64 syscall=execve success=yes exit=0 a0=1cfe460 a1=1cfe580 a2=1cfce40 a3=7ffff2789570 items=0 ppid=12444 pid=12445 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm=ldconfig exe=/sbin/ldconfig subj=unconfined_u:system_r:ldconfig_t:s0-s0:c0.c1023 key=(null)
:
:Hash: ldconfig,ldconfig_t,mock_var_lib_t,chr_file,write
:
:audit2allow
:
:#============= ldconfig_t ==============
:allow ldconfig_t mock_var_lib_t:chr_file write;
:
:audit2allow -R
:
:#============= ldconfig_t ==============
:allow ldconfig_t mock_var_lib_t:chr_file write;
:

Comment 1 Daniel Walsh 2011-10-12 13:20:43 UTC
Ankur, just want to make sure your real /dev/null is not labeled mock_var_lib_t.

ls -lZ /dev/null

How are you using mock?

Comment 2 Ankur Sinha (FranciscoD) 2011-10-12 13:52:10 UTC
Hi Daniel,

[root@ankur ~]# ls -lZ /dev/null
crw-rw-rw-. root root system_u:object_r:null_device_t:s0 /dev/null


Uhm, I just updated to f16 beta and used mock in the "normal" way. Set it up etc, then 

mock -v -r <config> rebuild <srpm>

Thanks,
Ankur

Comment 3 Daniel Walsh 2011-10-12 14:05:34 UTC
Is this the only AVC you saw?

Comment 4 Ankur Sinha (FranciscoD) 2011-10-12 14:52:59 UTC
Hi Dan.

Yes. It was iirc. I tried to run mock again to reproduce it, but was unable to. Maybe I had done something wrong, not set up mock correctly or something. I guess the ticket can be closed and I'll open a fresh one if it happens again.

Thanks,
Ankur

Comment 5 Daniel Walsh 2011-10-12 15:45:06 UTC
Well I am just trying to figure out how the redirection happened.

I think it is a real bug, and am not sure necessarily how the transitions would happen.

./setrans mock_t ldconfig_t
mock_t --> mount_t --> insmod_t --> initrc_t --> ldconfig_t


So there is a path between the two.

Not sure how the /dev/null that is in the /var/lib/mock could be passed though.

Comment 6 Daniel Walsh 2011-11-23 14:52:55 UTC
Are you still seeing this?

Comment 7 Miroslav Grepl 2011-12-05 11:50:01 UTC
*** Bug 757177 has been marked as a duplicate of this bug. ***

Comment 8 Clark Williams 2012-06-07 17:28:37 UTC
Has anyone been able to duplicate this bug?

Comment 9 Daniel Walsh 2012-06-07 18:59:47 UTC
Lets close it, I have not heard of it again.