Bug 450418 - rsyslog fails to read custom kernel System.map file due to SELinux
rsyslog fails to read custom kernel System.map file due to SELinux
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: rsyslog (Show other bugs)
9
i686 Linux
low Severity low
: ---
: ---
Assigned To: Peter Vrabec
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-07 22:46 EDT by Alessandro Suardi
Modified: 2008-06-14 07:32 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-14 07:32:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alessandro Suardi 2008-06-07 22:46:00 EDT
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 04:36:14 EDT
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 07:32:57 EDT
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.

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