On 5/30/05, Valdis.Kletnieks(a)vt.edu <Valdis.Kletnieks(a)vt.edu> wrote:
On Mon, 30 May 2005 11:33:28 CDT, Justin Conover said:
OK, with this info, I'm convinced that (a) you're not nuts, (b) your system is
labelled the way we told it to be labelled, and (c) we told it the wrong thing. ;)
Not so fast on "A" :D
> # lvcreate -L2G -nLogVol10 VolGroup00
> Logical volume "LogVol10" created
>
> # mkfs.ext3 /dev/VolGroup00/LogVol10
> mke2fs 1.37 (21-Mar-2005)
> Could not stat /dev/VolGroup00/LogVol10 --- Permission denied
Could you do a 'ls -lZ /dev/VolGroup00'? I'd like to verify that lvcreate
left LogVol10 labelled correctly - although I suspect that it got left what
lvm thought it should be, and the policy wanted something else....
# ls -lZ /dev/VolGroup00
lrwxrwxrwx root root system_u:object_r:device_t
LogVol00 -> /dev/mapper/VolGroup00-LogVol00
lrwxrwxrwx root root system_u:object_r:device_t
LogVol01 -> /dev/mapper/VolGroup00-LogVol01
lrwxrwxrwx root root system_u:object_r:device_t
LogVol02 -> /dev/mapper/VolGroup00-LogVol02
lrwxrwxrwx root root system_u:object_r:device_t
LogVol03 -> /dev/mapper/VolGroup00-LogVol03
lrwxrwxrwx root root system_u:object_r:device_t
LogVol04 -> /dev/mapper/VolGroup00-LogVol04
lrwxrwxrwx root root system_u:object_r:device_t
LogVol05 -> /dev/mapper/VolGroup00-LogVol05
lrwxrwxrwx root root system_u:object_r:device_t
LogVol06 -> /dev/mapper/VolGroup00-LogVol06
lrwxrwxrwx root root system_u:object_r:device_t
LogVol07 -> /dev/mapper/VolGroup00-LogVol07
lrwxrwxrwx root root system_u:object_r:device_t
LogVol08 -> /dev/mapper/VolGroup00-LogVol08
lrwxrwxrwx root root system_u:object_r:device_t
LogVol10 -> /dev/mapper/VolGroup00-LogVol10
> # grep mkfs audit/audit.log
> type=AVC msg=audit(1117397418.851:206892): avc: denied { getattr }
> for pid=2247 comm="mkfs.ext3" name=fedora.img dev=dm-7 ino=12
> scontext=root:system_r:fsadm_t tcontext=root:object_r:file_t
> tclass=file
This one looks like an attempt to scribble on a file called fedora.img -
can you do a 'grep dm-7 /proc/mounts' and then do a 'find /filesys -name
fedora.img -ls' and perhaps ls -lZ the file?
fedora.img is part of some Xen stuff I was doing, which initially
started this whole thing of mkfs not working.
(Anybody recognize this one? I'm guessing it's a mkinitrd and
dm-7 is /tmp...)
> type=AVC msg=audit(1117397783.921:261196): avc: denied { getattr }
> for pid=2308 comm="mkfs.ext3" name=fedora.img dev=dm-7 ino=12
> scontext=root:system_r:fsadm_t tcontext=root:object_r:file_t
> tclass=file
Another one of the same...
> type=AVC msg=audit(1117470602.109:1094349): avc: denied { getattr }
> for pid=4009 comm="mkfs.ext3" name=VolGroup00-LogVol10 dev=tmpfs
> ino=56551 scontext=root:system_r:fsadm_t
> tcontext=root:object_r:device_t tclass=blk_file
Here's the one that's causing yu the pain, and yes, it's borked up, and no,
it doesn't apear to be your fault - the system (lvm in particular) could be
doing a better job of labelling...
Hmm.. I'll place bets that if you do a 'mkfs.ext3 /dev/dm-N' that it will
work
just fine, as they're created as fixed_disk_device_t. At least on my box, the
symlink entries in /dev/VolGroup00 are being created as 'device_t' - and the
targets in /dev/mapper are tmpfs_t (quite borked) of all things.
Fortuitously, we have this in fsadm.te:
# for /dev/shm
allow fsadm_t tmpfs_t:dir { getattr search };
allow fsadm_t tmpfs_t:file { read write };
which seems to be likely to allow the access for all the wrong reasons.
I'm thinking the symlinks in /dev/VolGroup00 should be fixed_disk_device_t rather
than device_t - do others concur? And I'm suspecting the stuff in /dev/mapper
needs to be set to fixed_disk_device_t as well - that way the /dev/dm-* and
/dev/mapper/* entries for the same device are the same type (a nasty security
exposure otherwise...)
How do we get lvm to DTRT here? We can add a line to file_contexts/program/lvm.fc
to fix the /dev/mapper entries:
--- file_contexts/program/lvm.fc.dist 2005-05-20 14:53:12.000000000 -0400
+++ file_contexts/program/lvm.fc 2005-05-30 13:10:03.000000000 -0400
@@ -12,6 +12,7 @@
/etc/lvm/lock(/.*)? system_u:object_r:lvm_lock_t
/var/lock/lvm(/.*)? system_u:object_r:lvm_lock_t
/dev/lvm -c system_u:object_r:fixed_disk_device_t
+/dev/mapper/.* -c system_u:object_r:fixed_disk_device_t
/dev/mapper/control -c system_u:object_r:lvm_control_t
/lib/lvm-10/.* -- system_u:object_r:lvm_exec_t
/lib/lvm-200/.* -- system_u:object_r:lvm_exec_t
At least on my system, that leaves the /dev/mapper/* entries more sane....
(Justin - the above patch won't fly unless you have policy-sources installed.
If you're feeling brave, crazy, and adventurous, make a similar change to
/etc/selinux/strict/contexts/files/file_contexts, and then do a
'restorecon -v -R /dev' - make sure to save a backup of file_contexts first.. ;)
After that, you *should* be able to do a 'mkfs.ext3
/dev/mapper/VolGroup00-LogVol10'
But that still leaves the symlinks in /dev/VolGroup00 set wrong. Do we need
to add a 'follow symlink' in lvm.te? We can't fix this one in the
file_contexts,
because that dirname is essentially user-selected - on my system it's /dev/rootvg
(guess who comes from an AIX background? ;)
Or is there other borkedness here, and that it's the /dev/mapper/* that's
causing
Justin's indigestion, but we're reporting the context of the symlink rather than
the target that's actually failing? (Anybody want to devise a quick test case
for this one?)
I have no problem doing some of this if someone else chimes in too,
it's a new box I'm working on so there is nothing that a new install
wont cure for a borked system.