On Fri, 12 Mar 2004 01:01, Daniel J Walsh <dwalsh@xxxxxxxxxx> 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
