Bug 239401 - SELINUX=enforcing and SELINUXTYPE=strict causes kernel panic
SELINUX=enforcing and SELINUXTYPE=strict causes kernel panic
Status: CLOSED NOTABUG
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: realtime-kernel (Show other bugs)
1.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Eric Paris
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-08 03:16 EDT by IBM Bug Proxy
Modified: 2008-02-27 14:57 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-22 17:15:40 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)
selinux panic boot log (LTC id 27692) (15.11 KB, text/plain)
2007-05-08 03:16 EDT, IBM Bug Proxy
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
IBM Linux Technology Center 34440 None None None Never

  None (edit)
Description IBM Bug Proxy 2007-05-08 03:16:38 EDT
LTC Owner is: ankigarg@in.ibm.com
LTC Originator is: ankigarg@in.ibm.com


Problem description:

If this is not an installation problem, No.
       Provide output from "uname -a", if possible:

Linux llm49.in.ibm.com 2.6.20-0119.rt8 #1 SMP PREEMPT Thu Feb 15 15:53:15 CET
2007 x86_64 x86_64 x86_64 GNU/Linux

Hardware Environment
    Machine type (p650, x235, SF2, etc.): LS20
    Cpu type (Power4, Power5, IA-64, etc.): Dual Core AMD Opteron

Is this reproducible?
Setting SELINUX=enforcing and SELINUXTYPE=strict in /etc/selinux/config results
in the panic on next boot.

Creating an attachment (LTC id 27692)
selinux panic boot log

- Ankita

-------------------------------------------------------

Is this related to CONFIG_CPUSETS? Do we need CONFIG_CPUSETS enabled in RHEL5-RT? 

- Sripathi
Comment 1 IBM Bug Proxy 2007-05-08 03:16:38 EDT
Created attachment 154316 [details]
selinux panic boot log (LTC id 27692)
Comment 2 IBM Bug Proxy 2007-05-10 08:10:25 EDT
----- Additional Comments From ankigarg@in.ibm.com (prefers email at ankita@in.ibm.com)  2007-05-10 08:04 EDT -------
Found that the selinux-policy-strict is required when SELINUX=strict. This
package is not installed on RHEL by default. When I tried with
system-config-selinux, 'strict' option was not even present. The
selinux-policy-targeted is very much installed. So, I believe I hit this issue
because the strict policy is not being recognized by the system.

I tried to find the mentioned rpm package for RHEL, but could not. It is not
present in ftp3 also. Once I have the package, I can confirm whether I still hit
the same issue with it. 
Comment 3 IBM Bug Proxy 2007-05-14 07:25:39 EDT
----- Additional Comments From ankigarg@in.ibm.com (prefers email at ankita@in.ibm.com)  2007-05-14 07:19 EDT -------
I installed selinux-policy-strict package and got the following:

audit(1179160367.947:2): enforcing=1 old_enforcing=0 auid=4294967295
security:  class dccp_socket not defined in policy
security:  permission dccp_recv in class node not defined in policy
security:  permission dccp_send in class node not defined in policy
security:  permission dccp_recv in class netif not defined in policy
security:  permission dccp_send in class netif not defined in policy
audit(1179160368.447:3): policy loaded auid=4294967295
audit(1179160368.447:4): avc:  denied  { execute } for  pid=1 comm="init"
name="libsepol.so.1" dev=sda1 ino=130888 scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:lib_t:s0 tclass=file
Kernel panic - not syncing: Attempted to kill init!

Call Trace:
 [<ffffffff8106d5a4>] dump_trace+0xaa/0x32a
 [<ffffffff8106d865>] show_trace+0x41/0x5c
 [<ffffffff8106d895>] dump_stack+0x15/0x17
 [<ffffffff81091c8d>] panic+0xaf/0x169
 [<ffffffff8101558e>] do_exit+0xb4/0x894
 [<ffffffff8104a857>] cpuset_exit+0x0/0x6e
 [<ffffffff8104e3f4>] sys_exit_group+0x12/0x14
 [<ffffffff8105f11e>] system_call+0x7e/0x83
 [<0000003f85e13aa8>]

So, looks like this could be related to CPUSETS !! 
Comment 4 IBM Bug Proxy 2007-05-14 07:26:11 EDT
----- Additional Comments From ankigarg@in.ibm.com (prefers email at ankita@in.ibm.com)  2007-05-14 07:23 EDT -------
CONFIG_CPUSETS is enabled on RHEL5rt 
Comment 5 IBM Bug Proxy 2007-05-14 08:40:33 EDT
----- Additional Comments From ankigarg@in.ibm.com (prefers email at ankita@in.ibm.com)  2007-05-14 08:38 EDT -------
Taking help from Srinivasa, who has worked in selinux related stuff! 
Comment 6 Daniel Walsh 2007-05-15 12:03:54 EDT
Did you relabel the system in permissive mode?  When you change from targeted to
strict policy, you need to relabel in permissive mode the first time.
Comment 7 IBM Bug Proxy 2007-05-18 01:40:38 EDT
----- Additional Comments From ankigarg@in.ibm.com (prefers email at ankita@in.ibm.com)  2007-05-18 01:38 EDT -------
As suggested, I first booted into permissive mode and created a .autorelabel
file in root filesystem to enable relabeling on the next reboot. On successive
reboot into strict type, the kernel booted fine with no panic. So, the issue was
with no relabeling of the filesystem. 
Comment 8 IBM Bug Proxy 2007-05-18 01:45:24 EDT
changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |REJECTED
         Resolution|                            |NOTABUG




------- Additional Comments From ankigarg@in.ibm.com (prefers email at ankita@in.ibm.com)  2007-05-18 01:39 EDT -------
Rejecting this as NOT_A_BUG. 
Comment 9 Tim Burke 2007-05-22 17:15:40 EDT
Based on above comment, changing status on the RH bugzilla side to closed/notabug.
Comment 10 IBM Bug Proxy 2007-05-23 08:26:08 EDT
changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REJECTED                    |CLOSED




------- Additional Comments From sripathi@in.ibm.com (prefers email at sripathik@in.ibm.com)  2007-05-23 08:20 EDT -------
Moving to CLOSED. 

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