Wierdness with lsm 2.5

Wierdness with lsm 2.5

[Timothy Wood]

Has anyone been using the 2.5 lsm since the last release?  I'm getting a
whole lot of errors the 2.4 never gave me.  Here are some of them.

-----md errors------

avc:  denied  { getattr } for  pid=121 exe=/sbin/fsck path=/dev/md0
dev=03:03 ino=66778 scontext=system_u:system_r:fsadm_t
tcontext=system_u:object_r:device_t tclass=blk_file

avc:  denied  { getattr } for  pid=121 exe=/sbin/fsck path=/dev/md10
dev=03:03 ino=65551 scontext=system_u:system_r:fsadm_t
tcontext=system_u:object_r:device_t tclass=blk_file

avc:  denied  { getattr } for  pid=121 exe=/sbin/fsck path=/dev/md0
dev=03:03 ino=66778 scontext=system_u:system_r:fsadm_t
tcontext=system_u:object_r:device_t tclass=blk_file

avc:  denied  { getattr } for  pid=121 exe=/sbin/fsck path=/dev/md1
dev=03:03 ino=65550 scontext=system_u:system_r:fsadm_t
tcontext=system_u:object_r:device_t tclass=blk_file

avc:  denied  { getattr } for  pid=121 exe=/sbin/fsck path=/dev/md2
dev=03:03 ino=66782 scontext=system_u:system_r:fsadm_t
tcontext=system_u:object_r:device_t tclass=blk_file

avc:  denied  { getattr } for  pid=121 exe=/sbin/fsck path=/dev/md3
dev=03:03 ino=66792 scontext=system_u:system_r:fsadm_t
tcontext=system_u:object_r:device_t tclass=blk_file

avc:  denied  { getattr } for  pid=121 exe=/sbin/fsck path=/dev/md4
dev=03:03 ino=66794 scontext=system_u:system_r:fsadm_t
tcontext=system_u:object_r:device_t tclass=blk_file

avc:  denied  { getattr } for  pid=121 exe=/sbin/fsck path=/dev/md5
dev=03:03 ino=65554 scontext=system_u:system_r:fsadm_t
tcontext=system_u:object_r:device_t tclass=blk_file

avc:  denied  { getattr } for  pid=121 exe=/sbin/fsck path=/dev/md6
dev=03:03 ino=65555 scontext=system_u:system_r:fsadm_t
tcontext=system_u:object_r:device_t tclass=blk_file

avc:  denied  { getattr } for  pid=121 exe=/sbin/fsck path=/dev/md7
dev=03:03 ino=65556 scontext=system_u:system_r:fsadm_t
tcontext=system_u:object_r:device_t tclass=blk_file

AVC: 501642 messages suppressed.

--------some wierd device -----------
(new thing in 2.5 kernel I guess, disks of some sort or another)

avc:  denied  { getattr } for  pid=121 exe=/sbin/fsck
path=/dev/cciss/c2d4p14 dev=03:03 ino=2425518
scontext=system_u:system_r:fsadm_t tcontext=system_u:object_r:device_t
tclass=blk_file

avc:  denied  { getattr } for  pid=121 exe=/sbin/fsck
path=/dev/cciss/c4d10p6 dev=03:03 ino=2425893
scontext=system_u:system_r:fsadm_t tcontext=system_u:object_r:device_t
tclass=blk_file

AVC: 626927 messages suppressed.

avc:  denied  { getattr } for  pid=121 exe=/sbin/fsck
path=/dev/cciss/c6d2p7 dev=03:03 ino=2426517
scontext=system_u:system_r:fsadm_t tcontext=system_u:object_r:device_t
tclass=blk_file

AVC: 627109 messages suppressed.

avc:  denied  { getattr } for  pid=121 exe=/sbin/fsck path=/dev/hitcd
dev=03:03 ino=66633 scontext=system_u:system_r:fsadm_t
tcontext=system_u:object_r:device_t tclass=blk_file


-------some other wierd thing.

avc:  denied  { sys_tty_config } for  pid=721 comm=sh capability=26
scontext=system_u:system_r:checkpc_t
tcontext=system_u:system_r:checkpc_t tclass=capability


There are several other "messages suppressed" messages and several other
things on the system that do not work.  for example I have two
partitions on this test machine, a /boot and a /.  The / mounts fine but
the /boot won't mount.  

Does anyone know off the top of their head what the /dev/cciss is for? 
I see a lot of disk devices noted in a solaris fashion (eg c0d0p0s2 etc
etc instead of hda1 hda2 etc etc) 

Any thoughts welcome.

Timothy,

BTW, I did install this overtop of my lsm2.4 so that maybe messed it up?


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Wierdness with lsm 2.5

[Stephen Smalley]

On 10 Jul 2002, Timothy Wood wrote:

> Has anyone been using the 2.5 lsm since the last release?  I'm getting a
> whole lot of errors the 2.4 never gave me.  Here are some of them.

First, you should be very cautious about using 2.5, as it is the
development kernel series and can be very unsafe to use.  I wouldn't
recommend using it for any production systems.

> -----md errors------
>
> avc:  denied  { getattr } for  pid=121 exe=/sbin/fsck path=/dev/md0
> dev=03:03 ino=66778 scontext=system_u:system_r:fsadm_t
> tcontext=system_u:object_r:device_t tclass=blk_file

The md[0-9]* devices are for metadisk (RAID) devices.  See
Documentation/devices.txt in the kernel tree.  Ed Street noted earlier
that entries for these devices are missing from the current types.fc
configuration.  We've added them to our internal tree, and you can pull an
updated copy from the sourceforge CVS tree, or just add the following
directly to your types.fc file.  Then do a make relabel.  [Or, if using
devfs, you'll need to update your genfs_contexts configuration, do
a make install, and reboot].
/dev/ataraid/d[^/]*             system_u:object_r:fixed_disk_device_t
/dev/md[0-9]*                   system_u:object_r:fixed_disk_device_t

> --------some wierd device -----------
> (new thing in 2.5 kernel I guess, disks of some sort or another)
>
> avc:  denied  { getattr } for  pid=121 exe=/sbin/fsck
> path=/dev/cciss/c2d4p14 dev=03:03 ino=2425518
> scontext=system_u:system_r:fsadm_t tcontext=system_u:object_r:device_t
> tclass=blk_file

devices.txt identifies these as devices for Compaq Next Generation Drive
Array. Feel free to add entries to the types.fc to assign
fixed_disk_device_t to these devices [or update genfs_contexts if using
devfs].

> avc:  denied  { getattr } for  pid=121 exe=/sbin/fsck path=/dev/hitcd
> dev=03:03 ino=66633 scontext=system_u:system_r:fsadm_t
> tcontext=system_u:object_r:device_t tclass=blk_file

This would be a Hitachi CD-ROM.  Assign removable_device_t to it in
types.fc or genfs_contexts.

> -------some other wierd thing.
>
> avc:  denied  { sys_tty_config } for  pid=721 comm=sh capability=26
> scontext=system_u:system_r:checkpc_t
> tcontext=system_u:system_r:checkpc_t tclass=capability

Yes, I've seen this as well.  Many legacy suser() checks have been
replaced with capable() calls in 2.5, so you need to add capabilities to
the policy.  We haven't updated the example policy for this yet.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.