Bug 125477 - selinux contexts no longer set/restored
Summary: selinux contexts no longer set/restored
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: policy
Version: 2
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-06-07 21:04 UTC by Tom London
Modified: 2014-01-21 22:49 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-06-14 18:56:23 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
typescript of failing install of kernel-2.6.6-1.427.... (28.99 KB, application/x-bzip)
2004-06-10 18:12 UTC, Tom London
no flags Details

Description Tom London 2004-06-07 21:04:26 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510

Description of problem:
Running latest packages off of development tree, with SELinux enabled,
strict mode. (kernel-2.6.6-1.422)

After 'yum update' or 'yum install', the file contexts are not set
according to the context info in the package nor the context info in
the installed policy file.

I don't know when this stopped working. Also, I'm not certain this is
a yum issue..... (possibly rpm?).

Here are a few mislabeled files reported by 'fixfiles check' after
install of coreutils and canna (only a subset of complete listing):

/usr/sbin/setfiles:  relabeling /bin/su from system_u:object_r:bin_t
to system_u:object_r:su_exec_t
/usr/sbin/setfiles:  relabeling /usr/bin/catdic from
system_u:object_r:bin_t to system_u:object_r:canna_exec_t
/usr/sbin/setfiles:  relabeling /usr/bin/rfcomm from
system_u:object_r:bin_t to system_u:object_r:bluetooth_exec_t
/usr/sbin/setfiles:  relabeling /usr/bin/cannaping from
system_u:object_r:bin_t to system_u:object_r:canna_exec_t



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

How reproducible:
Always

Steps to Reproduce:
1. system, with SELinux/strict/enforcing
2. yum install or yum update
3.
    

Additional info:

Work around:

'fixfiles relabel' or 'setfiles ....' after install

Comment 1 Jeff Johnson 2004-06-10 02:08:08 UTC
yum knows nada about contexts, changing component to rpm.

I suspect that the problem is recent changes in the file
path to find file context regexes. That should be
fixed in rpm-4.3.2-0.1 and later. If not, please reopen.

Comment 2 Tom London 2004-06-10 18:12:33 UTC
Created attachment 101042 [details]
typescript of failing install of kernel-2.6.6-1.427....

Comment 3 Tom London 2004-06-10 18:13:33 UTC
Sorry... but I've reopened this.

I've attached a script showing an attepmt to 'yum update' that fails
for kernel pkg with a flurry of protection errors when run with an
SELinux/strict/enforcing system.  Basically, files installed into
/lib/modules have the wrong context, so mkinitrd fails (as does the
install).  Here are a few messages, including the FATAL one from mkinitrd:

    WARNING: Couldn't stat
/lib/modules/2.6.6-1.427/build/include/asm-i386/serial.h: Permission
denied
    WARNING: Couldn't stat /lib/modules/2.6.6-1.427/build/mm/Makefile:
Permission denied
    FATAL: Could not open /lib/modules/2.6.6-1.427/modules.dep.temp
for writing: Permission denied
    /bin/bash: /root/.bashrc: Permission denied
    No dep file found for kernel 2.6.6-1.427
    mkinitrd failed

Here is an 'ls -lZ' of /lib/modules after the 'install:
    [root@dell modules]# ls -lZ
    drwxr-xr-x  root     root     system_u:object_r:modules_object_t
2.6.5-1.358
    drwxr-xr-x  root     root     system_u:object_r:modules_object_t
2.6.6-1.422
    drwxr-xr-x  root     root     system_u:object_r:modules_object_t
2.6.6-1.424
    drwxr-xr-x  root     root     system_u:object_r:lib_t         
2.6.6-1.427

Notice that /lib/modules/2.6.6-1.427 has type 'lib_t', not
'modules_object_t'.

When run in strict/permissive mode, you still get most of the
warnings, but the mkinitrd succeeds. The files have the wrong context
labels, its just that permissive mode allows the process to continue.

My workaround is to only install new kernel packages when running in
permissive mode, and then to manually relabel /boot and /lib/modules
(using 'setfiles').
 

Comment 4 Jeff Johnson 2004-06-10 21:17:40 UTC
If the symptom is works in permissive but fails in enforcing,
then the problem is purely one of policy, not rpm.

Apologies for my mistaken guess.

Off to policy-sources for a "fix" ...

Comment 5 Tom London 2004-06-10 22:10:25 UTC
Here's an additional comment from Stephen Smalley that may help:

On Tue, 2004-06-08 at 23:25, Tom London wrote:
> [On my system, yum/rpm seem not to be correctly labeling installed 
> files, so I manually check and change via 'fixfiles' or 'setfiles' as 
> appropriate.

This is because rpm hasn't been updated for the new policy layout, so it
cannot find the file_contexts configuration.  Until it is updated, I
have just created a symlink, i.e.
ln -sf /etc/selinux/strict/contexts/files/file_contexts
/etc/security/selinux/file_contexts

-- 
Stephen Smalley <sds epoch ncsc mil>
National Security Agency

Comment 6 Daniel Walsh 2004-06-14 18:56:23 UTC
Latest RPM available in rawhide fixes this problem.

rpm-4.3.2-0.2


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