On 5/30/05, Valdis.Kletnieks@xxxxxx <Valdis.Kletnieks@xxxxxx> 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.