Bug 236282 - avc denial of depmod breaking kernel installation
avc denial of depmod breaking kernel installation
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
All Linux
medium Severity high
: ---
: ---
Assigned To: Anaconda Maintenance Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-12 16:32 EDT by Zack Cerza
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-13 15:40:59 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)

  None (edit)
Description Zack Cerza 2007-04-12 16:32:48 EDT
Description of problem:
It looks like /boot is getting the wrong selinux context assigned to it, and
that's breaking kernel installs.

This is a fresh install from yesterday's rawhide. Let me know if you need more
information besides this.

type=AVC msg=audit(1176389371.100:67): avc:  denied  { search } for  pid=4767
comm="depmod" name="/" dev=sda1 ino=2 scontext=system_u:system_r:depmod_t:s0
tcontext=system_u:object_r:file_t:s0 tclass=dir

drwxr-xr-x  root root system_u:object_r:file_t         boot

Version-Release number of selected component (if applicable):
selinux-policy-targeted-2.5.12-1.fc7
Comment 1 Daniel Walsh 2007-04-12 16:57:24 EDT
This should not happen.  file_t indicates that the /boot partition never got a
label during the install.  I am transferring this to anaconda.  

What Platform
Comment 2 Zack Cerza 2007-04-12 18:59:00 EDT
I just got these three, which might be relevant, after resuming from a
hibernate. Let me know if any of them warrant another report.

avc: denied { getattr } for comm="01grub" dev=sda1 egid=0 euid=0 exe="/bin/bash"
exit=0 fsgid=0 fsuid=0 gid=0 items=0 name="vmlinuz-2.6.20-1.3056.fc7"
path="/boot/vmlinuz-2.6.20-1.3056.fc7" pid=9742
scontext=system_u:system_r:hald_t:s0 sgid=0 subj=system_u:system_r:hald_t:s0
suid=0 tclass=file tcontext=system_u:object_r:default_t:s0 tty=(none) uid=0

avc: denied { read } for comm="grubby" dev=sda1 egid=0 euid=0 exe="/sbin/grubby"
exit=3 fsgid=0 fsuid=0 gid=0 items=0 name="grub.conf" pid=9747
scontext=system_u:system_r:hald_t:s0 sgid=0 subj=system_u:system_r:hald_t:s0
suid=0 tclass=file tcontext=user_u:object_r:file_t:s0 tty=(none) uid=0

avc: denied { write } for comm="grub" dev=sda3 egid=0 euid=0 exe="/sbin/grub"
exit=0 fsgid=0 fsuid=0 gid=0 items=0 name="pm-suspend.log"
path="/var/log/pm-suspend.log" pid=9752
scontext=system_u:system_r:bootloader_t:s0 sgid=0
subj=system_u:system_r:bootloader_t:s0 suid=0 tclass=file
tcontext=system_u:object_r:hald_log_t:s0 tty=(none) uid=0
Comment 3 Zack Cerza 2007-04-12 19:00:40 EDT
The platform is i386, btw.
Comment 4 Zack Cerza 2007-04-13 11:49:44 EDT
I opened bug #236391 for the grub denials.
Comment 5 Jeremy Katz 2007-04-13 12:57:52 EDT
Normal install or install from live CD?
Comment 6 Zack Cerza 2007-04-13 12:59:02 EDT
Live USB, baby.
Comment 7 Jeremy Katz 2007-04-13 15:40:59 EDT
Okay, should be fixed in CVS (looks so from my test at least) 
Comment 8 Will Woods 2007-04-13 16:03:27 EDT
'fixfiles restore /boot' serves as a workaround in the meantime. Or, you know,
'setenforce 0' before installing kernel / running mkinitrd.

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