Bug 121213 - compiling stock kernels for selinux didn't work
compiling stock kernels for selinux didn't work
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: policy (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-04-19 05:10 EDT by Thomas Molina
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-06-14 14:26:24 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)
configuration file used to build the kernel (24.93 KB, text/plain)
2004-04-19 05:12 EDT, Thomas Molina
no flags Details
dmesg output from failed boot attempt (15.53 KB, text/plain)
2004-04-19 05:14 EDT, Thomas Molina
no flags Details
new /var/log/messages after fixing compile options (37.13 KB, text/plain)
2004-04-20 05:54 EDT, Thomas Molina
no flags Details
updated bootlog (29.73 KB, text/plain)
2004-04-21 19:58 EDT, Thomas Molina
no flags Details

  None (edit)
Description Thomas Molina 2004-04-19 05:10:25 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040312

Description of problem:
I updated my local copy of the bitkeeper kernel tree, and added
selinux options to an existing, working, configuration.  I then
compiled and installed the resulting kernel.  I booted this kernel
into permissive selinux mode and was not able to log in because of the
numerous policy-related messages seen during boot up.  I then dropped
down to single user mode and did a "fixfiles relabel" and tried again
with no success.  I rebooted again after adding selinux=0 to the
command line with no problems.  This produced a normally functioning
system.  The FAQ seems to suggest that fixfiles relabel should resolve
the problem, but it doesn't seem to in this case.

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


How reproducible:
Always

Steps to Reproduce:
1.  compile and install a stock kernel
2.  boot into permissive selinux mode
3.  numerous policy failures are seen
    

Additional info:
Comment 1 Thomas Molina 2004-04-19 05:12:43 EDT
Created attachment 99528 [details]
configuration file used to build the kernel

Following are the SELINUX options:

#
# Security options
#
CONFIG_SECURITY=y
# CONFIG_SECURITY_NETWORK is not set
# CONFIG_SECURITY_CAPABILITIES is not set
# CONFIG_SECURITY_ROOTPLUG is not set
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
# CONFIG_SECURITY_SELINUX_MLS is not set
Comment 2 Thomas Molina 2004-04-19 05:14:03 EDT
Created attachment 99529 [details]
dmesg output from failed boot attempt
Comment 3 Thomas Molina 2004-04-19 05:17:03 EDT
The above errors during boot were seen on a boot subsequent to doing a
fixfiles relabel.
Comment 4 Thomas Molina 2004-04-20 05:54:22 EDT
Created attachment 99554 [details]
new /var/log/messages after fixing compile options

Someone passed on some additional options I needed to enable to get the compile
working.  This allowed me to recompile and boot correctly.  I am still getting
the attached messages in the log which don't occur when booting a redhat
kernel.
Comment 5 Colin Walters 2004-04-21 17:23:23 EDT
There are a few errors mixed together here.

First, you need to relabel your filesystem; your /usr/X11R6/bin/XOrg
has the wrong type.

Secondly, FAM is incompatible with SELinux.  I added a workaround for
this in the latest FAM to simply disable itself if SELinux is enabled.

The xauth bits I have to look into more...

Anyways, can you do a relabel and update to the latest rawhide to
verify that the first two are fixed?  Thanks.
Comment 6 Thomas Molina 2004-04-21 19:58:28 EDT
Created attachment 99617 [details]
updated bootlog

I ran up2date this afternoon (21 April) and did a fixfiles relabel as suggested
with little change in behaviour.  The xattr problems are gone, but I still see
the Xorg problems remain.  Most of it looks like normal glitches, expected in
development.  The things that bother me the most are the unlabeled attributes. 
How can a relabeled filesystem have unlabeled objects?
Comment 7 Daniel Walsh 2004-05-28 10:31:25 EDT
/initrd being still mounted is the problem.  Basically files within
this directory are unlabeled_t.

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