Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 228366 - LSPP: audit does not log obj label for signal recipient
Summary: LSPP: audit does not log obj label for signal recipient
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Alexander Viro
QA Contact: Brian Brock
URL:
Whiteboard:
: 230144 (view as bug list)
Depends On:
Blocks: RHEL5LSPPCertTracker
TreeView+ depends on / blocked
 
Reported: 2007-02-12 20:07 UTC by Amy Griffis
Modified: 2009-06-19 15:02 UTC (History)
7 users (show)

Fixed In Version: RHBA-2007-0959
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-11-07 19:40:02 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2007:0959 normal SHIPPED_LIVE Updated kernel packages for Red Hat Enterprise Linux 5 Update 1 2007-11-08 00:47:37 UTC

Description Amy Griffis 2007-02-12 20:07:29 UTC
Description of problem:

Audit does not log an obj label for the pid(s) which are sent signals via the
kill(), tkill(), tgkill() syscalls. Because MLS checks are performed for these
operations, audit must log the obj label in order to meet LSPP certification
requirements.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. send SIGKILL to process 15112
# kill -9 15112
  
Actual results:

type=SYSCALL msg=audit(1171310608.827:109140): arch=c000003e syscall=62
success=yes exit=0 a0=3b86 a1=9 a2=3b86 a3=0 items=0 ppid=15112 pid=15239
auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1
comm="do_kill" exe="/usr/local/eal4_testing/audit-test/utils/bin/do_kill"
subj=staff_u:lspp_test_r:lspp_test_generic_t:s0-s15:c0.c1023 key=(null)

Expected results:

type=SYSCALL msg=audit(1171310608.827:109140): arch=c000003e syscall=62
success=yes exit=0 a0=3b86 a1=9 a2=3b86 a3=0 items=1 ppid=15112 pid=15239
auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1
comm="do_kill" exe="/usr/local/eal4_testing/audit-test/utils/bin/do_kill"
subj=staff_u:lspp_test_r:lspp_test_generic_t:s0-s15:c0.c1023 key=(null)

type=TARGET_PID msg=audit(1171310608.827:109140): opid=15112
obj=staff_u:lspp_test_r:lspp_test_generic_t:s0-s15:c0.c1023

Additional info:

Comment 1 Irina Boverman 2007-02-14 21:30:44 UTC
per 2/12 discussion, Amy is reworking this patch and will make it available for
review shortly.

Comment 2 Eric Paris 2007-02-19 17:21:26 UTC
Patches were made available.  However, at sgrubb's request they were not
included in LSPP.65.  sgrubb is supposed to be soliciting upstream review from
Al Viro on this patch set.

Comment 3 Eric Paris 2007-02-23 21:49:49 UTC
note to self: s390_signal_class undefined in upstream patch submission. (see
audit_compat.c)

Comment 4 Eric Paris 2007-02-23 21:52:26 UTC
might also have problems on sparc32 (RHEL doesn't care, but this comment is also
about the upstream submission)

Comment 5 Eric Paris 2007-03-05 21:55:09 UTC
*** Bug 230144 has been marked as a duplicate of this bug. ***

Comment 6 Eric Paris 2007-03-09 19:47:00 UTC
Bug 230144 was a problem with this path on non-biarch systems.  We panic in
audit_receive_filter because on line 1231 we call:

     (entry->rule.mask[i] & classes[AUDIT_CLASS_SIGNAL_32][i]))

On a non biarch system (like i686) only the native AUDIT_CLASS_SIGNAL is
defined.  So referencing the classes array way out at AUDIT_CLASS_SIGNAL_32 is
just pointing at random crap.  Could be fixed with a bit of arch ifdef hacking,
but putting arch specific code in auditsc.c like that seems like a really really
bad idea.

*********************

Second problem found is that __audit_signal_info can be called from a interupt
context.  So the GFP_KERNEL allocation in that function may sleep.  See the
backtrace below:

kernel: BUG: sleeping function called from invalid context at mm/slab.c:2948
kernel: in_atomic():1, irqs_disabled():0
kernel:
kernel: Call Trace:
kernel:  <IRQ>  [<ffffffff8000abc5>] kmem_cache_alloc+0x2a/0xeb
kernel:  [<ffffffff800ba112>] __audit_signal_info+0xad/0xf0
kernel:  [<ffffffff8009824b>] check_kill_permission+0x5d/0x13f
kernel:  [<ffffffff8005b3df>] group_send_sig_info+0x18/0x6f
kernel:  [<ffffffff800991ee>] send_group_sig_info+0x28/0x3e
kernel:  [<ffffffff80091ad3>] it_real_fn+0x26/0x52
kernel:  [<ffffffff80091aad>] it_real_fn+0x0/0x52
kernel:  [<ffffffff8004f89c>] hrtimer_run_queues+0x10e/0x176
kernel:  [<ffffffff800971d7>] run_timer_softirq+0x23/0x1be
kernel:  [<ffffffff80012722>] __do_softirq+0x67/0xf3
kernel:  [<ffffffff8005ef04>] call_softirq+0x1c/0x28
kernel:  [<ffffffff8006e12f>] do_softirq+0x35/0xa0
kernel:  [<ffffffff8005e86f>] apic_timer_interrupt+0x6b/0x70
kernel:  <EOI>  [<ffffffff80050881>] d_delete+0x21/0xe6
kernel:  [<ffffffff800a5741>] lock_acquire+0x8d/0x9c
kernel:  [<ffffffff80050881>] d_delete+0x21/0xe6
kernel:  [<ffffffff80066053>] _spin_lock+0x1e/0x27
kernel:  [<ffffffff80050881>] d_delete+0x21/0xe6
kernel:  [<ffffffff8004a6bf>] vfs_unlink+0xe9/0x108
kernel:  [<ffffffff8003e00c>] do_unlinkat+0xaf/0x146
kernel:  [<ffffffff8005dd7a>] tracesys+0x71/0xdb
kernel:  [<ffffffff8005ddda>] tracesys+0xd

Comment 7 Eric Paris 2007-03-09 19:48:41 UTC
The current version of the patch is being pulled from the .68 LSPP kernel build.

Comment 9 George C. Wilson 2007-04-02 20:16:28 UTC
Was included in current kernel. Awaiting retest.

Comment 11 Eric Paris 2007-04-05 22:01:42 UTC
A patch for this bug from amg is currently in the LSPP kernels.  It has been
posted to linux-audit 

http://www.mail-archive.com/linux-audit@redhat.com/msg01118.html

would it be possible for someone from HP to test that this patch appears to be
working properly?

Comment 12 Amy Griffis 2007-04-05 22:07:41 UTC
This patch appears correct. We see the expected audit records and haven't seen
any panics.

Comment 15 Alexander Viro 2007-05-25 14:13:07 UTC
patch posted on rhkernel-list

Comment 16 Don Zickus 2007-06-12 18:42:32 UTC
in 2.6.18-24.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5

Comment 18 John Poelstra 2007-08-27 18:37:02 UTC
A fix for this issue should have been included in the packages contained in the
RHEL5.1-Snapshot3 on partners.redhat.com.  

Requested action: Please verify that your issue is fixed as soon as possible to
ensure that it is included in this update release.

After you (Red Hat Partner) have verified that this issue has been addressed,
please perform the following:
1) Change the *status* of this bug to VERIFIED.
2) Add *keyword* of PartnerVerified (leaving the existing keywords unmodified)

If this issue is not fixed, please add a comment describing the most recent
symptoms of the problem you are having and change the status of the bug to FAILS_QA.

More assistance: If you cannot access bugzilla, please reply with a message to
Issue Tracker and I will change the status for you.  If you need assistance
accessing ftp://partners.redhat.com, please contact your Partner Manager.

Comment 19 John Poelstra 2007-08-31 00:29:29 UTC
A fix for this issue should have been included in the packages contained in the
RHEL5.1-Snapshot4 on partners.redhat.com.  

Requested action: Please verify that your issue is fixed *as soon as possible*
to ensure that it is included in this update release.

After you (Red Hat Partner) have verified that this issue has been addressed,
please perform the following:
1) Change the *status* of this bug to VERIFIED.
2) Add *keyword* of PartnerVerified (leaving the existing keywords unmodified)

If this issue is not fixed, please add a comment describing the most recent
symptoms of the problem you are having and change the status of the bug to FAILS_QA.

If you cannot access bugzilla, please reply with a message to Issue Tracker and
I will change the status for you.  If you need assistance accessing
ftp://partners.redhat.com, please contact your Partner Manager.


Comment 20 John Poelstra 2007-09-11 19:23:29 UTC
A fix for this issue should have been included in the packages contained in the
RHEL5.1-Snapshot6 on partners.redhat.com.  

Requested action: Please verify that your issue is fixed ASAP to confirm that it
will be included in this update release.

After you (Red Hat Partner) have verified that this issue has been addressed,
please perform the following:
1) Change the *status* of this bug to VERIFIED.
2) Add *keyword* of PartnerVerified (leaving the existing keywords unmodified)

If this issue is not fixed, please add a comment describing the most recent
symptoms of the problem you are having and change the status of the bug to FAILS_QA.

If you cannot access bugzilla, please reply with a message to Issue Tracker and
I will change the status for you.  If you need assistance accessing
ftp://partners.redhat.com, please contact your Partner Manager.

Comment 21 Linda Knippers 2007-09-13 17:52:21 UTC
I've tested this with RHEL5 U1 snapshot 6.

Comment 23 errata-xmlrpc 2007-11-07 19:40:02 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2007-0959.html



Note You need to log in before you can comment on or make changes to this bug.