mkinitrd problems - 2 slightly different ones...

Running the fedora-devel code as of 0419.. hitting some issues
with installing a new kernel due to mkinitrd failing.

System has 1 disk, using LVM for the root filesystem - the bigger error seems
to be LVM-specific (looks  like bootloader_t needs to be able to do stuff
with lvm_exec_t and lvm_etc_t).

First, a quick example of shooting yourself in the foot:

# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10          
                                                          
(wheel) context=root:sysadm_r:sysadm_t

# /sbin/mkinitrd -v /boot/initrd-2.6.5-1.327.img 2.6.5-1.327
Looking for deps of module ide-disk     
/sbin/mkinitrd: line 1: /bin/ls: Permission denied
Looking for deps of module ext3  jbd
Looking for deps of module jbd  
Looking for deps of module dm-mod       
Using modules:  ./kernel/fs/jbd/jbd.ko ./kernel/fs/ext3/ext3.ko
./kernel/drivers/md/dm-mod.ko
Using loopback device /dev/loop0
rm: cannot get current directory: Permission denied
/sbin/nash -> /tmp/initrd.Y15570/bin/nash
/sbin/insmod.static -> /tmp/initrd.Y15570/bin/insmod
copy from /lib/modules/2.6.5-1.327/./kernel/fs/jbd/jbd.ko(elf32-i386) to
/tmp/initrd.Y15570/lib/jbd.ko(elf32-i386)
copy from /lib/modules/2.6.5-1.327/./kernel/fs/ext3/ext3.ko(elf32-i386) to
/tmp/initrd.Y15570/lib/ext3.ko(elf32-i386)
copy from /lib/modules/2.6.5-1.327/./kernel/drivers/md/dm-mod.ko(elf32-i386) to
/tmp/initrd.Y15570/lib/dm-mod.ko(elf32-i386)
/sbin/lvm.static -> /tmp/initrd.Y15570/bin/lvm
cp: cannot open `/sbin/lvm.static' for reading: Permission denied
/etc/lvm -> /tmp/initrd.Y15570/etc/lvm
`/etc/lvm/lvm.conf' -> `/tmp/initrd.Y15570/etc/lvm/lvm.conf'
cp: cannot open `/etc/lvm/lvm.conf' for reading: Permission denied
Loading module jbd
Loading module ext3
Loading module dm-mod
rm: cannot get current directory: Permission denied
rm: remove.c:378: AD_pop_and_chdir: Assertion `AD_stack_height (ds)' failed.
/sbin/mkinitrd: line 678: 15649 Aborted                 rm -rf $MNTIMAGE $MNTPOINT $IMAGE
#

Ouch. Gotta love that final 'rm' error. :)

How did I cause that?  I was stupidly still cd'ed into
/etc/security/selinux/src/policy at the time. ;)

Got *tons* of these:

Apr 19 22:31:27 orange kernel: audit(1082428287.917:0): avc:  denied  { search } for 
pid=15434 exe=/bin/bash name=policy dev=dm-0 ino=85034 scontext=root:sysadm_r:bootloader_t
tcontext=system_u:object_r:policy_src_t tclass=dir

and here's the one that killed the rm command, I think:

Apr 19 22:31:28 orange kernel: audit(1082428288.257:0): avc:  denied  { search } for 
pid=15649 exe=/bin/rm name=policy dev=dm-0 ino=85034 scontext=root:sysadm_r:bootloader_t
tcontext=system_u:object_r:policy_src_t tclass=dir

(total of 88 failed 'search' - odd part is that I did NOT have '.' in my
$PATH).

OK, so take 2 - this gets rid of the 88 failed search requests:

# cd /
#  /sbin/mkinitrd -v /boot/initrd-2.6.5-1.327.img 2.6.5-1.327
Looking for deps of module ide-disk     
/sbin/mkinitrd: line 1: /bin/ls: Permission denied
Looking for deps of module ext3  jbd
Looking for deps of module jbd  
Looking for deps of module dm-mod       
Using modules:  ./kernel/fs/jbd/jbd.ko ./kernel/fs/ext3/ext3.ko
./kernel/drivers/md/dm-mod.ko
Using loopback device /dev/loop0
/sbin/nash -> /tmp/initrd.f15792/bin/nash
/sbin/insmod.static -> /tmp/initrd.f15792/bin/insmod
copy from /lib/modules/2.6.5-1.327/./kernel/fs/jbd/jbd.ko(elf32-i386) to
/tmp/initrd.f15792/lib/jbd.ko(elf32-i386)
copy from /lib/modules/2.6.5-1.327/./kernel/fs/ext3/ext3.ko(elf32-i386) to
/tmp/initrd.f15792/lib/ext3.ko(elf32-i386)
copy from /lib/modules/2.6.5-1.327/./kernel/drivers/md/dm-mod.ko(elf32-i386) to
/tmp/initrd.f15792/lib/dm-mod.ko(elf32-i386)
/sbin/lvm.static -> /tmp/initrd.f15792/bin/lvm
cp: cannot open `/sbin/lvm.static' for reading: Permission denied
/etc/lvm -> /tmp/initrd.f15792/etc/lvm
`/etc/lvm/lvm.conf' -> `/tmp/initrd.f15792/etc/lvm/lvm.conf'
cp: cannot open `/etc/lvm/lvm.conf' for reading: Permission denied
Loading module jbd
Loading module ext3
Loading module dm-mod

A bit better - here's the remaining avc messages:

Apr 19 22:36:44 orange kernel: audit(1082428604.698:0): avc:  denied  { execute } for 
pid=15696 exe=/bin/bash name=dmsetup dev=dm-0 ino=65548
scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:lvm_exec_t tclass=file
Apr 19 22:36:44 orange kernel: audit(1082428604.698:0): avc:  denied  { read } for 
pid=15696 exe=/bin/bash name=dmsetup dev=dm-0 ino=65548
scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:lvm_exec_t tclass=file
Apr 19 22:36:44 orange kernel: audit(1082428604.729:0): avc:  denied  { execute } for 
pid=15711 exe=/bin/bash name=ls dev=dm-0 ino=16424 scontext=root:sysadm_r:bootloader_t
tcontext=system_u:object_r:ls_exec_t tclass=file
Apr 19 22:36:44 orange kernel: audit(1082428604.729:0): avc:  denied  { read } for 
pid=15711 exe=/bin/bash name=ls dev=dm-0 ino=16424 scontext=root:sysadm_r:bootloader_t
tcontext=system_u:object_r:ls_exec_t tclass=file
Apr 19 22:36:46 orange kernel: SELinux: initialized (dev loop0, type ext2), uses xattr
Apr 19 22:36:47 orange kernel: audit(1082428607.002:0): avc:  denied  { read } for 
pid=15834 exe=/bin/cp name=lvm.static dev=dm-0 ino=72206
scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:lvm_exec_t tclass=file
Apr 19 22:36:47 orange kernel: audit(1082428607.007:0): avc:  denied  { read } for 
pid=15835 exe=/bin/cp name=lvm.conf dev=dm-0 ino=82396 scontext=root:sysadm_r:bootloader_t
tcontext=system_u:object_r:lvm_etc_t tclass=file

[Colin Walters]

On Mon, 2004-04-19 at 22:50, Valdis.Kletnieks(a)vt.edu wrote:
>  Running the fedora-devel code as of 0419.. hitting some issues
>  with installing a new kernel due to mkinitrd failing.
>  
>  System has 1 disk, using LVM for the root filesystem - the bigger error seems
>  to be LVM-specific (looks  like bootloader_t needs to be able to do stuff
>  with lvm_exec_t and lvm_etc_t). 
I don't think anyone here has really messed seriously with SELinux and
LVM yet.  Looks like you are the lucky winner :)

>  rm: remove.c:378: AD_pop_and_chdir: Assertion `AD_stack_height
> (ds)' failed. 
Nice.  I think many applications were written with the idea that they
would always have permissions to the current working directory.

>  How did I cause that?  I was stupidly still cd'ed into
> /etc/security/selinux/src/policy at the time. ;) 
Yeah.

>  Apr 19 22:36:44 orange kernel: audit(1082428604.698:0): avc:  denied 
> { execute } for  pid=15696 exe=/bin/bash name=dmsetup dev=dm-0 ino=65548
> scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:lvm_exec_t tclass=file
>  Apr 19 22:36:44 orange kernel: audit(1082428604.698:0): avc:  denied  { read } for 
> pid=15696 exe=/bin/bash name=dmsetup dev=dm-0 ino=65548
> scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:lvm_exec_t tclass=file
>  Apr 19 22:36:44 orange kernel: audit(1082428604.729:0): avc:  denied  { execute } for 
> pid=15711 exe=/bin/bash name=ls dev=dm-0 ino=16424 scontext=root:sysadm_r:bootloader_t
> tcontext=system_u:object_r:ls_exec_t tclass=file
>  Apr 19 22:36:44 orange kernel: audit(1082428604.729:0): avc:  denied  { read } for 
> pid=15711 exe=/bin/bash name=ls dev=dm-0 ino=16424 scontext=root:sysadm_r:bootloader_t
> tcontext=system_u:object_r:ls_exec_t tclass=file
>  Apr 19 22:36:46 orange kernel: SELinux: initialized (dev loop0, type ext2), uses xattr
>  Apr 19 22:36:47 orange kernel: audit(1082428607.002:0): avc:  denied  { read } for 
> pid=15834 exe=/bin/cp name=lvm.static dev=dm-0 ino=72206
> scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:lvm_exec_t tclass=file
>  Apr 19 22:36:47 orange kernel: audit(1082428607.007:0): avc:  denied  { read } for 
> pid=15835 exe=/bin/cp name=lvm.conf dev=dm-0 ino=82396 scontext=root:sysadm_r:bootloader_t
> tcontext=system_u:object_r:lvm_etc_t tclass=file 
I added stuff to try to fix this into policy, will be in the next
upload.  Patch attached, let me know if it works for you...

On Mon, 19 Apr 2004 23:12:29 EDT, Colin Walters <walters(a)redhat.com&gt;  said:

>  I added stuff to try to fix this into policy, will be in the next
>  upload.  Patch attached, let me know if it works for you... 
Almost right, it needs lvm_etc_t as well - fixed patch attached,
thanks for the fast feedback...

[Colin Walters]

On Mon, 2004-04-19 at 23:25, Valdis.Kletnieks(a)vt.edu wrote:
>  On Mon, 19 Apr 2004 23:12:29 EDT, Colin Walters
> <walters(a)redhat.com&gt;  said:
>  
>  > I added stuff to try to fix this into policy, will be in the next
>  > upload.  Patch attached, let me know if it works for you...
>  
>  Almost right, it needs lvm_etc_t as well - fixed patch attached,
>  thanks for the fast feedback... 
Ah, that was actually a typo in my original patch.  If you change the
r_dir_file(bootloader_t, lvm_t)
to 
r_dir_file(bootloader_t, lvm_etc_t)
does it work?

On Mon, 19 Apr 2004 23:32:55 EDT, Colin Walters <walters(a)redhat.com&gt;  said:

>  Ah, that was actually a typo in my original patch.  If you change
> the
>  r_dir_file(bootloader_t, lvm_t)
>  to
>  r_dir_file(bootloader_t, lvm_etc_t)
>  does it work? 
Yes, that works too...

Tomorrow's job:  Figure out why /bin/ls and /bin/rm died just because
I was cd'ed to the wrong place when I did the initrd, even though they weren't
being asked to do anything with $PWD.. ;)

[Russell Coker]

On Tue, 20 Apr 2004 12:50, Valdis.Kletnieks(a)vt.edu wrote:
>  Running the fedora-devel code as of 0419.. hitting some issues
>  with installing a new kernel due to mkinitrd failing.
>
>  System has 1 disk, using LVM for the root filesystem - the bigger error
>  seems to be LVM-specific (looks  like bootloader_t needs to be able to do
>  stuff with lvm_exec_t and lvm_etc_t). 
Regarding the issue of search access to the current directory.  One 
work-around is that if you are writing a program that launches such a fussy 
program then you can have it do "cd /" before the exec.

I have attached a patch for lvm that cleans up a few things (and also has some 
non-LVM changes that won't cause any harm), and a patch for bootloader.te 
which will hopefully fix this issue.

Please apply both patches, relabel /etc/lvm, and let me know how it goes.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

[Russell Coker]

On Wed, 21 Apr 2004 00:25, Russell Coker <russell(a)coker.com.au&gt; wrote:
>  On Tue, 20 Apr 2004 12:50, Valdis.Kletnieks(a)vt.edu wrote:
>  > Running the fedora-devel code as of 0419.. hitting some issues
>  > with installing a new kernel due to mkinitrd failing.
>  >
>  > System has 1 disk, using LVM for the root filesystem - the bigger error
>  > seems to be LVM-specific (looks  like bootloader_t needs to be able to do
>  > stuff with lvm_exec_t and lvm_etc_t).
>
>  Regarding the issue of search access to the current directory.  One
>  work-around is that if you are writing a program that launches such a fussy
>  program then you can have it do "cd /" before the exec.
>
>  I have attached a patch for lvm that cleans up a few things (and also has
>  some non-LVM changes that won't cause any harm), and a patch for
>  bootloader.te which will hopefully fix this issue.
>
>  Please apply both patches, relabel /etc/lvm, and let me know how it goes. 
It seems that my lvm patch was messed up, I didn't have the latest version.  
I've attached a new lvm.te that is correct.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

On Wed, 21 Apr 2004 01:45:10 +1000, Russell Coker said:

>  It seems that my lvm patch was messed up, I didn't have the
> latest version.  
>  I've attached a new lvm.te that is correct. 
Still needs some work:

# cd /
# /sbin/lvm lvcreate -n LogVol06 -L 2048M Volume00                         
  /var/lock/lvm/V_Volume00: open failed: Permission denied
  Can't get lock for Volume00
#

And these avc message:

Apr 20 16:23:51 orange kernel: audit(1082492631.510:0): avc:  denied  { getattr } for 
pid=3575 exe=/sbin/lvm.static path=/var/lock/lvm dev=dm-5 ino=12289
scontext=root:system_r:lvm_t tcontext=system_u:object_r:lvm_lock_t tclass=dir
Apr 20 16:23:51 orange kernel: audit(1082492631.511:0): avc:  denied  { read write search
} for  pid=3575 exe=/sbin/lvm.static name=lvm dev=dm-5 ino=12289
scontext=root:system_r:lvm_t tcontext=system_u:object_r:lvm_lock_t tclass=dir
Apr 20 16:23:51 orange kernel: audit(1082492631.511:0): avc:  denied  { search } for 
pid=3575 exe=/sbin/lvm.static name=lvm dev=dm-5 ino=12289 scontext=root:system_r:lvm_t
tcontext=system_u:object_r:lvm_lock_t tclass=dir
Apr 20 16:23:51 orange kernel: audit(1082492631.513:0): avc:  denied  { getattr } for 
pid=3575 exe=/sbin/lvm.static name=/ dev=dm-5 ino=2 scontext=root:system_r:lvm_t
tcontext=system_u:object_r:fs_t tclass=filesystem

(Yes, breaking stuff like this is part of my job :)