Re: AVC messages at boot and kdm login (latest Rawhide)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 11 Mar 2004 23:38, Aleksey Nogin <aleksey@xxxxxxxxx> wrote:
> Mar 11 04:19:44 dell kernel: audit(1079007536.909:0): avc:  denied  {
> execute } for  pid=15 exe=/sbin/init name=bash dev=hda2 ino=3662881
> scontext=system_u:system_r:init_t
> tcontext=system_u:object_r:shell_exec_t tclass=file

Why is init trying to execute the shell directly?  Surely it should be 
executing rc.sysinit, sulogin, or something else?

> Mar 11 04:19:49 dell kernel: audit(1079007547.555:0): avc:  denied  {
> mounton } for  pid=327 exe=/bin/mount path=/var/lib/rpc_pipes dev=hda2
> ino=425580 scontext=system_u:system_r:mount_t
> tcontext=system_u:object_r:var_lib_t tclass=dir

What is this about?

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

> 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.875:0): avc:  denied  {
> read write } for  pid=1661 exe=/usr/sbin/gpm name=gpmdata dev=hda2
> ino=72912 scontext=system_u:system_r:gpm_t
> tcontext=system_u:object_r:device_t tclass=fifo_file

That should have type gpmctl_t, I'll change gpm.fc.

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

> Mar 11 04:20:29 dell kernel: audit(1079007629.554:0): avc:  denied  {
> read } for  pid=2098 exe=/usr/bin/kdm name=mem dev=hda2 ino=2683359
> scontext=system_u:system_r:xdm_t
> tcontext=system_u:object_r:memory_device_t tclass=chr_file

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.

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

> Mar 11 04:20:52 dell kernel: audit(1079007652.936:0): avc:  denied  {
> entrypoint } for  pid=2131 exe=/usr/bin/kdm path=/etc/kde/kdm/Xsession
> dev=hda2 ino=1226634 scontext=user_u:user_r:user_t
> tcontext=system_u:object_r:etc_t tclass=file

/etc/kde/kdm/Xsession   --      system_u:object_r:xsession_exec_t

We need to add the above to xdm.fc.

> Mar 11 04:20:54 dell kernel: audit(1079007654.232:0): avc:  denied  {
> getattr } for  pid=2131 exe=/bin/tcsh path=/var/log/messages dev=hda2
> ino=3613840 scontext=user_u:user_r:user_t
> tcontext=system_u:object_r:var_log_t tclass=file

That is because the user is trying to do bad things.  The file is set mode 
0600 in Unix permissions and equivalent in SE Linux permissions by default.

> And another interesting one I saw later:
>
> Mar 11 04:21:32 dell kernel: audit(1079007691.925:0): avc:  denied  {
> search } for  pid=2363 exe=/usr/bin/ksysguardd
> scontext=user_u:user_r:user_t tcontext=system_u:object_r:sysctl_dev_t
> tclass=dir

The problem here is that the user wants access to lots of info on the machine, 
and we don't want to give it all up.  Maybe we can make this a tunable.

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



[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux