From mboxrd@z Thu Jan 1 00:00:00 1970 From: Amy Griffis Subject: Re: [PATCH 1/2] add SIGNAL syscall class Date: Wed, 14 Feb 2007 16:38:34 -0500 Message-ID: <20070214213834.GC19194@fc.hp.com> References: <20070214182431.GA17337@fc.hp.com> <200702141404.07353.sgrubb@redhat.com> <20070214201205.GA18196@fc.hp.com> <200702141532.02447.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Content-Disposition: inline In-Reply-To: <200702141532.02447.sgrubb@redhat.com> 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 List-Id: linux-audit@redhat.com Steve Grubb wrote: [Wed Feb 14 2007, 03:32:02PM EST] > On Wednesday 14 February 2007 15:12:05 Amy Griffis wrote: > > Steve Grubb wrote: [Wed Feb 14 2007, 02:04:07PM EST] > > > > > On Wednesday 14 February 2007 13:24:31 Amy Griffis wrote: > > > > Add a syscall class for sending signals. > > > > > > The intent of the syscall classes had been to make an update > > > independent way of being able to specify audit rules for > > > filesystem auditing where new syscalls could be added. > > > > Yeah, I know I used it in a different way from the original > > purpose. > > So, how does this work from a user perspective? Do you need to patch > auditctl? For now, only the kernel is using the signal syscall class. You wouldn't need to do anything in userspace. For the other signal audit patch, you would only need to add an entry for AUDIT_TARGET_PID in msg_typetab.h so the new record type is not logged as UNKNOWN. This reminds me, do we want/need to be able to filter on target pid? > > But I think this is still a valid use... When we are adding or > > removing a rule, we need a way to determine if the rule specified > > one of the syscalls for sending signals. > > Could you show a sample use? (Just so I understand what its doing.) It works like the audit_n_rules counter. When you add a rule specifying kill, tkill or tgkill the counter goes up. When you remove one of them, the counter goes down. If the counter is 0 when we hit the audit_signal_info hook, we don't collect the info about the target pid(s). That way we don't add unnecessary overhead to the call path. The signal class exists so we can see if the rule being added/removed contains any of those particular syscalls. Amy