Russell Coker wrote:
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?
This is a bug in the policy file. Anyone install the March 10th install
should update the policy file to policy-1.8-3 or greater. The init
script is executing rhgb script to put up graphical boot.
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?
This is something new with nfs-utils. Allows nfs util ability to
communicate with the kernel. Fixed in latest policy.
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
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.
Enter a bugzilla.
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.
