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
