AVC messages at boot and kdm login (latest Rawhide)
Daniel J Walsh
dwalsh at redhat.com
Thu Mar 11 14:01:53 UTC 2004
Russell Coker wrote:
>On Thu, 11 Mar 2004 23:38, Aleksey Nogin <aleksey at nogin.org> 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.
>
>
>
More information about the selinux
mailing list