From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Way too many logs! Date: Sat, 10 May 2008 21:17:57 -0400 Message-ID: <200805102117.58187.sgrubb@redhat.com> References: <482479DC020000100005CB37@gsi.gracon.com> <21796.1210368544@turing-police.cc.vt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <21796.1210368544@turing-police.cc.vt.edu> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com Cc: Valdis.Kletnieks@vt.edu List-Id: linux-audit@redhat.com On Friday 09 May 2008 17:29:04 Valdis.Kletnieks@vt.edu wrote: > On Fri, 09 May 2008 16:20:44 EDT, Jeremy Leonard said: > > -a exit,always -S sched_setparam -S sched_setscheduler -k RULE7 > > > > type=SYSCALL msg=audit(04/25/08 16:37:48.568:194518) : arch=i386 > > syscall=_newselect > > OK, I'll bite - why is a select() syscall tripping sched_setparam or > sched_setschdeduler? This record has a personality bit set unlike most events I ever see: "arch=i386 syscall=_newselect per=400000" I don't know if that is affecting the syscalls or not. Assuming it doesn't, _newselect only occurs on ppc as far as I know. Its syscall 142. On x86_64, sched_setparam is syscall 142. Not sure if that is the connection or not. But something is wrong in this audit event. :) Also notice that the subject is unconstrained, so they must be running some special SE Linux policy or have a very unique kernel. > Or more importantly - are those two cutting audit events for the wrong > reasons? Yeah, could be. I think I'd also want to audit the setting of the personality as that could be an attempt at masking the real actions of the user. Most systems never do this. If you have a system doing it, you might want to keep an eye on that. -Steve