From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Limiting SECCOMP audit events Date: Thu, 14 Dec 2017 10:29:38 -0500 Message-ID: <3367743.fjAuTK8mJQ@x2> References: <58203247.sCqcla2mis@x2> <17198747.0Wk1AduiP0@x2> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3108130692192665911==" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Paul Moore Cc: Linux Audit List-Id: linux-audit@redhat.com This is a multi-part message in MIME format. --===============3108130692192665911== Content-Type: multipart/alternative; boundary="nextPart1960055.1CyWegJSjn" Content-Transfer-Encoding: 7Bit This is a multi-part message in MIME format. --nextPart1960055.1CyWegJSjn Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Thursday, December 14, 2017 7:42:26 AM EST Paul Moore wrote: > >> Looking at the kernel code, it looks like the actions_logged knob > >> isn't really intended to filter/drop seccomp events, > > > > That's unfortunate. I thought this was a way to suppress generation of > > events. We have a requirement that audit events be selective by the > > administrator. We need a knob to drop some events. I guess, the only knob > > right now is the exclude filter. That is probably too course. > > > >> but rather force seccomp events to be loggged. Look at seccomp_log() to > >> see what I mean; there is still a call to audit_seccomp() at the end. > > > > Hmm. What do we do? > > I imagine we could put together a rather coarse grained action filter, > similar to what we have with "actions_logged" (maybe > "actions_silent"?), and perhaps add some additional audit filters for > seccomp for those who happen to have audit enabled. Both should be > relatively easy, the "actions_silent" field especially so. OK. That would be helpful. This is eating up my log space. The biggest offenders seem to be doing trap kind of events. I suppose if an errno was returned the program would respond by erroring out. But since its a trap, I suspect something looks around at data and then OK's it to proceed on which results in another trap. -Steve --nextPart1960055.1CyWegJSjn Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="us-ascii"

On Thursday, December 14, 2017 7:42:26 AM EST Paul Moore wrote:

> >> Looking at the kernel code, it looks like the actions_logged knob

> >> isn't really intended to filter/drop seccomp events,

> >

> > That's unfortunate. I thought this was a way to suppress generation of

> > events. We have a requirement that audit events be selective by the

> > administrator. We need a knob to drop some events. I guess, the only knob

> > right now is the exclude filter. That is probably too course.

> >

> >> but rather force seccomp events to be loggged. Look at seccomp_log() to

> >> see what I mean; there is still a call to audit_seccomp() at the end.

> >

> > Hmm. What do we do?

>

> I imagine we could put together a rather coarse grained action filter,

> similar to what we have with "actions_logged" (maybe

> "actions_silent"?), and perhaps add some additional audit filters for

> seccomp for those who happen to have audit enabled. Both should be

> relatively easy, the "actions_silent" field especially so.

 

OK. That would be helpful. This is eating up my log space. The biggest offenders seem to be doing trap kind of events. I suppose if an errno was returned the program would respond by erroring out. But since its a trap, I suspect something looks around at data and then OK's it to proceed on which results in another trap.

 

-Steve

--nextPart1960055.1CyWegJSjn-- --===============3108130692192665911== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============3108130692192665911==--