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:
per 2/12 discussion, Amy is reworking this patch and will make it available for review shortly.
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.
note to self: s390_signal_class undefined in upstream patch submission. (see audit_compat.c)
might also have problems on sparc32 (RHEL doesn't care, but this comment is also about the upstream submission)
*** Bug 230144 has been marked as a duplicate of this bug. ***
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
The current version of the patch is being pulled from the .68 LSPP kernel build.
Was included in current kernel. Awaiting retest.
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?
This patch appears correct. We see the expected audit records and haven't seen any panics.
patch posted on rhkernel-list
in 2.6.18-24.el5 You can download this test kernel from http://people.redhat.com/dzickus/el5
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.
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.
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.
I've tested this with RHEL5 U1 snapshot 6.
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