AVC messages at boot and kdm login (latest Rawhide)

[Russell Coker]

On Fri, 12 Mar 2004 01:01, Daniel J Walsh <dwalsh at redhat.com> wrote:
> >>Mar 11 04:19:49 dell kernel: audit(1079007583.849:0): avc:  denied  {
> >>dac_override } for  pid=1296 exe=/bin/bash capability=1
> >>scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:dhcpc_t
> >>tclass=capability
> >>Mar 11 04:19:50 dell kernel: audit(1079007590.445:0): avc:  denied  {
> >>fsetid } for  pid=1504 exe=/bin/chmod capability=4
> >>scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:dhcpc_t
> >>tclass=capability
> >
> >I guess it doesn't do any harm to add dac_override, I'll put it in my
> > tree.
> >
> >Why does it need fsetid?  What file is it chmod'ing?
>
> grep chmod /sbin/dhclient-script
>     chmod 644 /etc/resolv.conf

/* Overrides the following restrictions that the effective user ID
   shall match the file owner ID when setting the S_ISUID and S_ISGID
   bits on that file; that the effective group ID (or one of the
   supplementary group IDs) shall match the file owner ID when setting
   the S_ISGID bit on that file; that the S_ISUID and S_ISGID bits are
   cleared on successful return from chown(2) (not implemented). */

#define CAP_FSETID           4

Either something strange is being done or the kernel comment from capability.h 
is wrong.

I am hesitant to add fsetid without being sure of this, there's the issue of 
hiding bugs, and the potential problem of future policy allowing user_t to 
execute something that dhcpc_t can write and then allowing an inappropriate 
SETGID.

> >>Mar 11 04:19:53 dell kernel: audit(1079007591.541:0): avc:  denied  {
> >>dac_override } for  pid=1614 exe=/usr/sbin/sendmail.sendmail
> >>capability=1 scontext=system_u:system_r:sendmail_t
> >>tcontext=system_u:system_r:sendmail_t tclass=capability
> >
> >I'll look into this later.

> >>Mar 11 04:19:53 dell kernel: audit(1079007592.976:0): avc:  denied  {
> >>read write } for  pid=1665 exe=/usr/sbin/gpm name=event0 dev=hda2
> >>ino=4219044 scontext=system_u:system_r:gpm_t
> >>tcontext=system_u:object_r:device_t tclass=chr_file
> >>Mar 11 04:19:53 dell kernel: audit(1079007592.976:0): avc:  denied  {
> >>ioctl } for  pid=1665 exe=/usr/sbin/gpm path=/dev/input/event0 dev=hda2
> >>ino=4219044 scontext=system_u:system_r:gpm_t
> >>tcontext=system_u:object_r:device_t tclass=chr_file
> >
> >How does /dev/input really work?  As I understand it event0 could be a
> >keyboard or a mouse.  So maybe we want a separate type for this so that
> > when using gpm it can access it, but when the user is granted direct
> > mouse access they can't read the keyboard directly.
> >
> >Does this make sense?


> >That's a bug in kdm.  It should use /dev/random instead.  Reading arbitary
> >kernel memory as a source of random numbers is bogus anyway.
>
> Enter a bugzilla.

Done, #118123.

> >>Mar 11 04:20:36 dell kernel: audit(1079007636.465:0): avc:  denied  {
> >>read } for  pid=2112 exe=/usr/X11R6/bin/XFree86 name=event0 dev=hda2
> >>ino=4219044 scontext=system_u:system_r:xdm_xserver_t
> >>tcontext=system_u:object_r:device_t tclass=chr_file
> >
> >This will be easy to solve once we solve the gpm issue above.
> >
> >>Mar 11 04:20:42 dell kernel: audit(1079007642.899:0): avc:  denied  {
> >>write } for  pid=2121 exe=/usr/bin/kdm_greet name=.qtrc.lock dev=hda2
> >>ino=670527 scontext=system_u:system_r:xdm_t
> >>tcontext=system_u:object_r:lib_t tclass=file
> >
> >What directory is this in?  We just need to get the directory in question
> >labeled as var_lib_xdm_t.
> >
> >>Mar 11 04:20:52 dell kernel: audit(1079007652.672:0): avc:  denied  {
> >>setattr } for  pid=2113 exe=/usr/bin/kdm name=sg0 dev=hda2 ino=2688146
> >>scontext=system_u:system_r:xdm_t
> >>tcontext=system_u:object_r:scsi_generic_device_t tclass=chr_file
> >
> >dontaudit or allow?  What should we do?
> >
> >It probably doesn't matter much as the default policy does not permit the
> > user to access the SCSI generic device.

-- 
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