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. ;)
> # 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....
> # 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?
(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?)
Attachment:
pgp8tFfmgyJVh.pgp
Description: PGP signature
-- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-selinux-list
