Bug 121213 - compiling stock kernels for selinux didn't work
Summary: compiling stock kernels for selinux didn't work
Alias: None
Product: Fedora
Classification: Fedora
Component: policy   
(Show other bugs)
Version: rawhide
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2004-04-19 09:10 UTC by Thomas Molina
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-06-14 18:26:24 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
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 09:12 UTC, Thomas Molina
no flags Details
dmesg output from failed boot attempt (15.53 KB, text/plain)
2004-04-19 09:14 UTC, Thomas Molina
no flags Details
new /var/log/messages after fixing compile options (37.13 KB, text/plain)
2004-04-20 09:54 UTC, Thomas Molina
no flags Details
updated bootlog (29.73 KB, text/plain)
2004-04-21 23:58 UTC, Thomas Molina
no flags Details

Description Thomas Molina 2004-04-19 09:10:25 UTC
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:

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 09:12:43 UTC
Created attachment 99528 [details]
configuration file used to build the kernel

Following are the SELINUX options:

# Security options

Comment 2 Thomas Molina 2004-04-19 09:14:03 UTC
Created attachment 99529 [details]
dmesg output from failed boot attempt

Comment 3 Thomas Molina 2004-04-19 09:17:03 UTC
The above errors during boot were seen on a boot subsequent to doing a
fixfiles relabel.

Comment 4 Thomas Molina 2004-04-20 09:54:22 UTC
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

Comment 5 Colin Walters 2004-04-21 21:23:23 UTC
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 23:58:28 UTC
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 14:31:25 UTC
/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.