|Summary:||Changing from 'targeted' to 'strict' policy causes kernel panic.|
|Product:||[Fedora] Fedora||Reporter:||Nils Hammar <u60149431>|
|Component:||selinux-policy-strict||Assignee:||Daniel Walsh <dwalsh>|
|Status:||CLOSED NOTABUG||QA Contact:||Ben Levenson <benl>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2007-03-26 17:42:37 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Nils Hammar 2007-03-26 14:36:59 UTC
Description of problem: System hangs with Panic while booting and the following message: "/sbin/init: error while loading shared libraries: libsepol.so.1: failed to map segment from shared object: Permission denied" Version-Release number of selected component (if applicable): Kernel; kernel-2.6.20-1.2933.fc6 Policy Related; libselinux-python-1.33.4-2.fc6 libselinux-devel-1.33.4-2.fc6 libselinux-1.33.4-2.fc6 selinux-policy-2.4.6-42.fc6 selinux-policy-strict-2.4.6-42.fc6 selinux-policy-targeted-2.4.6-42.fc6 How reproducible: Always Steps to Reproduce: 1. Installation of Fedora Core 6, selecting 'Development' usage, and no customization of additional software. (Swedish sv-latin1 keyboard mapping) 2. Upgrading to latest patches with yum, "yum -y update" and reboot. 3. Installation of newrole package. 4. Changing from 'targeted' to 'strict' in either GUI or by editing /etc/sysconfig/selinux and trigging relabeling. 5. reboot. 6. System hangs early in the start with: "/sbin/init: error while loading shared libraries: libsepol.so.1: failed to map segment from shared object: Permission denied" Actual results: Expected results: No "Panic!" Additional info: Problem seems to be present for the "mls" policy too. Is it maybe a "catch 22" problem here where the shared library has to be relabeled in order to be accessed, but it can't be relabeled until the system is booted with the right policy?
Comment 1 Daniel Walsh 2007-03-26 17:42:37 UTC
In order to relabel to strict you must do it in permissive mode first. The problem is in targeted policy shared library files are labeled lib_t and in strict they are labeled shlib_t. So when init tries to execute a shared library it sees it is labeled lib_t and fails, and this happens before relabeling.