Bug 450418

Summary: rsyslog fails to read custom kernel System.map file due to SELinux
Product: [Fedora] Fedora Reporter: Alessandro Suardi <alessandro.suardi>
Component: rsyslogAssignee: Peter Vrabec <pvrabec>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 9CC: dwalsh, theinric
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-06-14 11:32:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Alessandro Suardi 2008-06-08 02:46:00 UTC
Description of problem:

Likely related to https://bugzilla.redhat.com/show_bug.cgi?id=436895
I'm not sure rsyslog is the proper package to file this bug under,
 as I just 'cp' System.map from my Linux source directory to /boot,
 and adding a restorecon just after that could work around the issue.

However, here it goes...


SELinux denies access to rsyslog for home-compiled kernel System.map file
 which is generated as

  unconfined_u:object_r:boot_t:s0

 instead of

  system_u:object_r:system_map_t:s0

Version-Release number of selected component (if applicable):

[asuardi@sandman ~]$ rpm -qa | egrep 'syslog|selinux' | sort
libselinux-2.0.64-2.fc9.i386
libselinux-devel-2.0.64-2.fc9.i386
libselinux-python-2.0.64-2.fc9.i386
rsyslog-3.14.1-2.fc9.i386
selinux-policy-3.3.1-55.fc9.noarch
selinux-policy-targeted-3.3.1-55.fc9.noarch


How reproducible:

100%


Steps to Reproduce:
1. build a home-compiled kernel (eg. 2.6.26-rc5-git2 from kernel.org)
2. copy relevant files in /boot
3. wait for rsyslogd to restart

  
Actual results:

Jun  8 04:17:27 sandman kernel: imklog 3.14.1, log source = /proc/kmsg started.
Jun  8 04:17:27 sandman kernel: Cannot find map file.
Jun  8 04:17:27 sandman kernel: No module symbols loaded - kernel modules not
enabled.
Jun  8 04:17:27 sandman kernel: cannot find any symbols, turning off symbol lookups
Jun  8 04:17:27 sandman rsyslogd: [origin software="rsyslogd" swVersion="3.14.1"
x-pid="1477" x-info="http://www.rsyslog.com"] restart
Jun  8 04:17:27 sandman setroubleshoot: SELinux is preventing rsyslogd
(syslogd_t) "read" to ./System.map-2.6.26-rc5 (boot_t). For complete SELinux
messages. run sealert -l f8269dbd-0c66-41be-bfa9-ad99552f6226


[root@sandman ~]# sealert -l f8269dbd-0c66-41be-bfa9-ad99552f6226

Summary:

SELinux is preventing rsyslogd (syslogd_t) "read" to ./System.map-2.6.26-rc5
(boot_t).

[...]


Expected results:

files copied in /boot have the proper context, and rsyslogd can read them


Additional info:

Here's how the System.map files appear:

[root@sandman ~]# ls -lZ /boot/System.map-2.6.2*
-rw-r--r--  root root system_u:object_r:system_map_t:s0
/boot/System.map-2.6.25.4-30.fc9.i686
-rw-r--r--  root root unconfined_u:object_r:boot_t:s0  /boot/System.map-2.6.26-rc5
-rw-r--r--  root root unconfined_u:object_r:boot_t:s0 
/boot/System.map-2.6.26-rc5-git2

(Fedora 9 default one is okay, custom-compiled ones aren't)

[root@sandman ~]# restorecon -v /boot/System.map-2.6.26-rc5-git2 
restorecon reset /boot/System.map-2.6.26-rc5-git2 context
unconfined_u:object_r:boot_t:s0->system_u:object_r:system_map_t:s0

(restorecon -v fixes it)

Comment 1 Peter Vrabec 2008-06-13 08:36:14 UTC
hmm, I really have no clue how to fix this. A plain copy creates the new file
following the default behaviour based on the domain of the creating process (cp)
and the type of the target directory. Creating a package for your custom kernel
might help. 

Lets ask Daniel if there is some common practise in this.




Comment 2 Daniel Walsh 2008-06-14 11:32:57 UTC
If you copy to a directory which has multiple context residing in it, you need
to reset the context your self.  There is no easy way for the system to do this.
 I believe cp/restorecon is the best solution.  You could theoretically use
restorecond, if this was a common occurrence.

You need to think of this the same way you think of DAC, in that you need to
make sure the permissions are ok on the file.