Re: seccomp and audit_enabled

[Paul Moore]

On Fri, Nov 20, 2015 at 12:51 PM, Tony Jones  wrote:
> Any comments on this?  Current interaction between enabled_enabled and dummy 
> flag seems wrong to me.   I can code up
> a patch.

It's on my todo list for this development cycle, I've just been a
little busy lately with the merge window and now some -rc1 testing.

-- 
paul moore
www.paul-moore.com
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: seccomp and audit_enabled

[Tony Jones]

On 10/13/2015 12:19 PM, Paul Moore wrote:

> Yes, if systemd is involved it enables audit; we've had some
> discussions with the systemd folks about fixing that, but they haven't
> gone very far.  I'm still a little curious as to why
> audit_dummy_context() is false in this case, but I haven't looked at
> how systemd/auditctl start/config the system too closely.

Sorry for the delay here. 

A context is allocated by audit_alloc() because there is no uid/gid filter for 
the task
but the dummy flag is left false.  Because audit has been disabled (manually 
following systemd enabling), 
dummy never gets set in the syscall entry path (based on !audit_n_rules). So 
the unlikely(!audit_dummy_context())
in audit_seccomp succeeds.  

Tony
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: seccomp and audit_enabled

[Tony Jones]

On 10/13/2015 01:03 PM, Steve Grubb wrote:
>> No, it's the default audit.rules (-D, -b320).   No actual rules loaded.
>> Let me add some instrumentation and figure out what's going on.  auditd
>> is masked (via systemd) but systemd-journal seems to set audit_enabled=1
>> during startup (at least on our systems).
> 
> Tony,
> 
> We have bz 1227379
> https://bugzilla.redhat.com/show_bug.cgi?id=1227379
> 
> There is a patch attached to disable systemd's propensity to turn on the 
> audit 
> system. Are people complaining and opening bugs in your distribution? If so, 
> that might add more ammunition to get that fixed.

Hi Steve

we only have the one bug and it's related to:
1) noisy klog between when systemd enables audit and user manually disables it 
(rh bz#1160046)
2) after user manually disables audit (audit_enabled=0) seccomp messages still 
are output.

tony
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: seccomp and audit_enabled

[Paul Moore]

On Mon, Oct 12, 2015 at 4:45 PM, Kees Cook  wrote:
> On Mon, Oct 12, 2015 at 10:53 AM, Tony Jones  wrote:
>> From d6971ec9508244f7a1ab42f9ac4c59b7e1ca6145 Mon Sep 17 00:00:00 2001
>> From: Tony Jones 
>> Date: Sat, 10 Oct 2015 19:30:49 -0700
>> Subject: [PATCH] Don't log seccomp messages when audit is disabled
>>
>> Don't log seccomp messages when audit is disabled.
>
> This is intentional since violation of a seccomp policy ought to
> indicate a misbehaving program, and we want these to always be
> presented to the system log, regardless of audit being enabled. (I'd
> like to even produce system log entries when there is no CONFIG_AUDIT
> too, but that's for the future.)

I agree.  As I mentioned earlier these AUDIT_SECCOMP records are very handy.

>> diff --git a/include/linux/audit.h b/include/linux/audit.h
>> index b2abc99..8f70f3f 100644
>> --- a/include/linux/audit.h
>> +++ b/include/linux/audit.h
>> @@ -113,6 +113,12 @@ struct filename;
>>
>>  extern void audit_log_session_info(struct audit_buffer *ab);
>>
>> +#ifdef CONFIG_AUDIT
>> +extern u32 audit_enabled;
>> +#else
>> +#define audit_enabled 0
>> +#endif
>> +
>>  #ifdef CONFIG_AUDIT_COMPAT_GENERIC
>>  #define audit_is_compat(arch)  (!((arch) & __AUDIT_ARCH_64BIT))
>>  #else
>> @@ -213,7 +219,7 @@ void audit_core_dumps(long signr);
>>  static inline void audit_seccomp(unsigned long syscall, long signr, int 
>> code)
>>  {
>> /* Force a record to be reported if a signal was delivered. */
>> -   if (signr || unlikely(!audit_dummy_context()))
>
> What is dummy_context part of this actually do? I don't think reports
> should be made when signr == 0.

The idea behind audit_dummy_context() is to skip auditing when there
are no audit rules configured, it's a performance tweak.  My guess is
that Tony's system loads some audit configuration at boot which
enables audit (the kernel starts with audit_enabled=0 ...) and loads a
few syscall filter rules which are enough to make
audit_dummy_context() return false.  Can you confirm that Tony?

As for logging seccomp actions when signr == 0, I personally think
that still might be useful as the normal behavior has been altered; I
tend to think any action != ALLOW is worth logging.  However, I'm open
to discussion on this if others feel strongly.

>> +   if (audit_enabled && (signr || unlikely(!audit_dummy_context(
>> __audit_seccomp(syscall, signr, code);
>>  }

-- 
paul moore
www.paul-moore.com
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: seccomp and audit_enabled

[Tony Jones]

On 10/13/2015 09:11 AM, Paul Moore wrote:
> On Mon, Oct 12, 2015 at 4:45 PM, Kees Cook  wrote:
>> On Mon, Oct 12, 2015 at 10:53 AM, Tony Jones  wrote:
>>> From d6971ec9508244f7a1ab42f9ac4c59b7e1ca6145 Mon Sep 17 00:00:00 2001
>>> From: Tony Jones 
>>> Date: Sat, 10 Oct 2015 19:30:49 -0700
>>> Subject: [PATCH] Don't log seccomp messages when audit is disabled
>>>
>>> Don't log seccomp messages when audit is disabled.
>>
>> This is intentional since violation of a seccomp policy ought to
>> indicate a misbehaving program, and we want these to always be
>> presented to the system log, regardless of audit being enabled. (I'd
>> like to even produce system log entries when there is no CONFIG_AUDIT
>> too, but that's for the future.)
> 
> I agree.  As I mentioned earlier these AUDIT_SECCOMP records are very handy.
> 
>>> diff --git a/include/linux/audit.h b/include/linux/audit.h
>>> index b2abc99..8f70f3f 100644
>>> --- a/include/linux/audit.h
>>> +++ b/include/linux/audit.h
>>> @@ -113,6 +113,12 @@ struct filename;
>>>
>>>  extern void audit_log_session_info(struct audit_buffer *ab);
>>>
>>> +#ifdef CONFIG_AUDIT
>>> +extern u32 audit_enabled;
>>> +#else
>>> +#define audit_enabled 0
>>> +#endif
>>> +
>>>  #ifdef CONFIG_AUDIT_COMPAT_GENERIC
>>>  #define audit_is_compat(arch)  (!((arch) & __AUDIT_ARCH_64BIT))
>>>  #else
>>> @@ -213,7 +219,7 @@ void audit_core_dumps(long signr);
>>>  static inline void audit_seccomp(unsigned long syscall, long signr, int 
>>> code)
>>>  {
>>> /* Force a record to be reported if a signal was delivered. */
>>> -   if (signr || unlikely(!audit_dummy_context()))
>>
>> What is dummy_context part of this actually do? I don't think reports
>> should be made when signr == 0.
> 
> The idea behind audit_dummy_context() is to skip auditing when there
> are no audit rules configured, it's a performance tweak.  My guess is
> that Tony's system loads some audit configuration at boot which
> enables audit (the kernel starts with audit_enabled=0 ...) and loads a
> few syscall filter rules which are enough to make
> audit_dummy_context() return false.  Can you confirm that Tony?

No, it's the default audit.rules (-D, -b320).   No actual rules loaded. 
Let me add some instrumentation and figure out what's going on.  auditd
is masked (via systemd) but systemd-journal seems to set audit_enabled=1 
during startup (at least on our systems).

> As for logging seccomp actions when signr == 0, I personally think
> that still might be useful as the normal behavior has been altered; I
> tend to think any action != ALLOW is worth logging.  However, I'm open
> to discussion on this if others feel strongly.
> 
>>> +   if (audit_enabled && (signr || unlikely(!audit_dummy_context(
>>> __audit_seccomp(syscall, signr, code);
>>>  }

I'm of the opinion that nothing should get output (through the audit system) if 
audit_enabled == 0.  What you advocate calls for more than 2 possible states 
for 
audit_enabled or logging the information through another mechanism than audit.

Tony

--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: seccomp and audit_enabled

[Tony Jones]

On 10/13/2015 12:19 PM, Paul Moore wrote:

>> No, it's the default audit.rules (-D, -b320).   No actual rules loaded.
>> Let me add some instrumentation and figure out what's going on.  auditd
>> is masked (via systemd) but systemd-journal seems to set audit_enabled=1
>> during startup (at least on our systems).
> 
> Yes, if systemd is involved it enables audit; we've had some
> discussions with the systemd folks about fixing that, but they haven't
> gone very far.  I'm still a little curious as to why
> audit_dummy_context() is false in this case, but I haven't looked at
> how systemd/auditctl start/config the system too closely.

I'll debug what's going on (easy) on the test system and report back.  I'm 
curious
too.  Have a bad cold today so I'm moving slower than normal.

> I don't really care if it is audit or not (although we will need to
> output something via audit if it is enabled to keep the CC crowd
> happy); if you feel strongly that it isn't audit, we can just make it
> a printk, that would work well with Kees' goals.  To me the important
> point here is that we send a message when seccomp alters the behavior
> of the syscall (action != ALLOW).

Yes, if audit is enabled, you should totally be able to use it. Rest sounds 
good also.

thanks!

Tony

--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: seccomp and audit_enabled

[Paul Moore]

On Friday, October 09, 2015 08:50:01 PM Tony Jones wrote:
> Hi.
> 
> What is the expected handling of AUDIT_SECCOMP if audit_enabled == 0?  
> Opera browser makes use of a sandbox and if audit_enabled == 0 (and no
> auditd is running) there is a lot of messages dumped to the klog. The fix
> to __audit_seccomp() is trivial, similar to c2412d91c and I can send a
> patch, I'm just not sure if seccomp is somehow special?

I'm adding Kees to this since he looks after the seccomp kernel bits these 
days.  While there isn't anything special about seccomp from an audit 
perspective, the seccomp audit record can be a really nice thing as it is the 
only indication you may get that seccomp has stepped in and done "something" 
other than allow the syscall to progress normally.

I would be a little more concerned that you are seeing a flood of seccomp 
messages from Opera, that is something that most likely warrants some closer 
inspection.  Are all the records the same/similar?  Can you paste some into 
email?

-- 
paul moore
www.paul-moore.com

--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: seccomp and audit_enabled

[Paul Moore]

My apologies for the resend, I had the wrong email for Kees.

On Monday, October 12, 2015 11:29:43 AM Paul Moore wrote:
> On Friday, October 09, 2015 08:50:01 PM Tony Jones wrote:
> > Hi.
> > 
> > What is the expected handling of AUDIT_SECCOMP if audit_enabled == 0?
> > Opera browser makes use of a sandbox and if audit_enabled == 0 (and no
> > auditd is running) there is a lot of messages dumped to the klog. The fix
> > to __audit_seccomp() is trivial, similar to c2412d91c and I can send a
> > patch, I'm just not sure if seccomp is somehow special?
> 
> I'm adding Kees to this since he looks after the seccomp kernel bits these
> days.  While there isn't anything special about seccomp from an audit
> perspective, the seccomp audit record can be a really nice thing as it is
> the only indication you may get that seccomp has stepped in and done
> "something" other than allow the syscall to progress normally.
> 
> I would be a little more concerned that you are seeing a flood of seccomp
> messages from Opera, that is something that most likely warrants some closer
> inspection.  Are all the records the same/similar?  Can you paste some into
> email?

-- 
paul moore
www.paul-moore.com

--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: seccomp and audit_enabled

[Tony Jones]

On 10/12/2015 08:40 AM, Paul Moore wrote:
> My apologies for the resend, I had the wrong email for Kees.
> 
> On Monday, October 12, 2015 11:29:43 AM Paul Moore wrote:
>> On Friday, October 09, 2015 08:50:01 PM Tony Jones wrote:
>>> Hi.
>>>
>>> What is the expected handling of AUDIT_SECCOMP if audit_enabled == 0?
>>> Opera browser makes use of a sandbox and if audit_enabled == 0 (and no
>>> auditd is running) there is a lot of messages dumped to the klog. The fix
>>> to __audit_seccomp() is trivial, similar to c2412d91c and I can send a
>>> patch, I'm just not sure if seccomp is somehow special?
>>
>> I'm adding Kees to this since he looks after the seccomp kernel bits these
>> days.  While there isn't anything special about seccomp from an audit
>> perspective, the seccomp audit record can be a really nice thing as it is
>> the only indication you may get that seccomp has stepped in and done
>> "something" other than allow the syscall to progress normally.

The issue is that (without auditd running) the messages are output to klog 
regardless 
of whether audit_enabled is 0 or 1.  As I said, other occurrences of this such 
as with
login events has been corrected (c2412d91c). Attached patch does same for 
seccomp.

>> I would be a little more concerned that you are seeing a flood of seccomp
>> messages from Opera, that is something that most likely warrants some closer
>> inspection.  Are all the records the same/similar?  Can you paste some into
>> email?

Here is the logged messages per invocation of opera.  the use of the sandbox 
may well
be the result of a local suse config/packaging decision but I'm not sure that's 
relevant.

2015-10-10T19:35:23.237882-07:00 nohostname kernel: [  152.100348] audit: 
type=1326 audit(1444530923.236:356): auid=1000 uid=1000 gid=100 ses=1 pid=2048 
comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c03e syscall=91 
compat=0 ip=0x7ff926d94ab7 code=0x5
2015-10-10T19:35:23.242867-07:00 nohostname kernel: [  152.105690] audit: 
type=1326 audit(1444530923.241:357): auid=1000 uid=1000 gid=100 ses=1 pid=2087 
comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c03e syscall=273 
compat=0 ip=0x7ff928325444 code=0x5
2015-10-10T19:35:23.242873-07:00 nohostname kernel: [  152.105938] audit: 
type=1326 audit(1444530923.241:358): auid=1000 uid=1000 gid=100 ses=1 pid=2089 
comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c03e syscall=273 
compat=0 ip=0x7ff928325444 code=0x5
2015-10-10T19:35:23.243890-07:00 nohostname kernel: [  152.106845] audit: 
type=1326 audit(1444530923.242:359): auid=1000 uid=1000 gid=100 ses=1 pid=2048 
comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c03e syscall=2 
compat=0 ip=0x7ff926d6daa1 code=0x3
2015-10-10T19:35:23.275872-07:00 nohostname kernel: [  152.138819] audit: 
type=1326 audit(1444530923.273:360): auid=1000 uid=1000 gid=100 ses=1 pid=2093 
comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c03e syscall=91 
compat=0 ip=0x7f92e4bd7ab7 code=0x5
2015-10-10T19:35:23.275885-07:00 nohostname kernel: [  152.138937] audit: 
type=1326 audit(1444530923.274:361): auid=1000 uid=1000 gid=100 ses=1 pid=2093 
comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c03e syscall=91 
compat=0 ip=0x7f92e4bd7ab7 code=0x5
2015-10-10T19:35:23.280867-07:00 nohostname kernel: [  152.143147] audit: 
type=1326 audit(1444530923.279:362): auid=1000 uid=1000 gid=100 ses=1 pid=2096 
comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c03e syscall=273 
compat=0 ip=0x7f92e6168444 code=0x5
2015-10-10T19:35:23.282055-07:00 nohostname kernel: [  152.144762] audit: 
type=1326 audit(1444530923.280:363): auid=1000 uid=1000 gid=100 ses=1 pid=2093 
comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c03e syscall=2 
compat=0 ip=0x7f92eb5f8587 code=0x5
2015-10-10T19:35:23.282062-07:00 nohostname kernel: [  152.144890] audit: 
type=1326 audit(1444530923.280:364): auid=1000 uid=1000 gid=100 ses=1 pid=2093 
comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c03e syscall=2 
compat=0 ip=0x7f92e4b2ac8c code=0x5
2015-10-10T19:35:23.282063-07:00 nohostname kernel: [  152.144988] audit: 
type=1326 audit(1444530923.280:365): auid=1000 uid=1000 gid=100 ses=1 pid=2093 
comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c03e syscall=2 
compat=0 ip=0x7f92e4b2ad70 code=0x5


thanks

tony


>From d6971ec9508244f7a1ab42f9ac4c59b7e1ca6145 Mon Sep 17 00:00:00 2001
From: Tony Jones 
Date: Sat, 10 Oct 2015 19:30:49 -0700
Subject: [PATCH] Don't log seccomp messages when audit is disabled

Don't log seccomp messages when audit is disabled.   

Currently, each time the opera browser is executed 10 records similar to the 
following are output to klog (when !audit_enabled).

2015-10-10T19:35:23.237882-07:00 nohostname kernel: [  152.100348] audit: 
type=1326 audit(1444530923.236:356): auid=1000 uid=1000 gid=100 ses=1 pid=2048 
comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c03e syscall=91 

Re: seccomp and audit_enabled

[Kees Cook]

On Mon, Oct 12, 2015 at 10:53 AM, Tony Jones  wrote:
> On 10/12/2015 08:40 AM, Paul Moore wrote:
>> My apologies for the resend, I had the wrong email for Kees.

(I keep asking for that alias, but no luck...)

>> On Monday, October 12, 2015 11:29:43 AM Paul Moore wrote:
>>> On Friday, October 09, 2015 08:50:01 PM Tony Jones wrote:
 Hi.

 What is the expected handling of AUDIT_SECCOMP if audit_enabled == 0?
 Opera browser makes use of a sandbox and if audit_enabled == 0 (and no
 auditd is running) there is a lot of messages dumped to the klog. The fix
 to __audit_seccomp() is trivial, similar to c2412d91c and I can send a
 patch, I'm just not sure if seccomp is somehow special?
>>>
>>> I'm adding Kees to this since he looks after the seccomp kernel bits these
>>> days.  While there isn't anything special about seccomp from an audit
>>> perspective, the seccomp audit record can be a really nice thing as it is
>>> the only indication you may get that seccomp has stepped in and done
>>> "something" other than allow the syscall to progress normally.
>
> The issue is that (without auditd running) the messages are output to klog 
> regardless
> of whether audit_enabled is 0 or 1.  As I said, other occurrences of this 
> such as with
> login events has been corrected (c2412d91c). Attached patch does same for 
> seccomp.
>
>>> I would be a little more concerned that you are seeing a flood of seccomp
>>> messages from Opera, that is something that most likely warrants some closer
>>> inspection.  Are all the records the same/similar?  Can you paste some into
>>> email?
>
> Here is the logged messages per invocation of opera.  the use of the sandbox 
> may well
> be the result of a local suse config/packaging decision but I'm not sure 
> that's relevant.
>
> 2015-10-10T19:35:23.237882-07:00 nohostname kernel: [  152.100348] audit: 
> type=1326 audit(1444530923.236:356): auid=1000 uid=1000 gid=100 ses=1 
> pid=2048 comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c03e 
> syscall=91 compat=0 ip=0x7ff926d94ab7 code=0x5
> 2015-10-10T19:35:23.242867-07:00 nohostname kernel: [  152.105690] audit: 
> type=1326 audit(1444530923.241:357): auid=1000 uid=1000 gid=100 ses=1 
> pid=2087 comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c03e 
> syscall=273 compat=0 ip=0x7ff928325444 code=0x5
> 2015-10-10T19:35:23.242873-07:00 nohostname kernel: [  152.105938] audit: 
> type=1326 audit(1444530923.241:358): auid=1000 uid=1000 gid=100 ses=1 
> pid=2089 comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c03e 
> syscall=273 compat=0 ip=0x7ff928325444 code=0x5
> 2015-10-10T19:35:23.243890-07:00 nohostname kernel: [  152.106845] audit: 
> type=1326 audit(1444530923.242:359): auid=1000 uid=1000 gid=100 ses=1 
> pid=2048 comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c03e 
> syscall=2 compat=0 ip=0x7ff926d6daa1 code=0x3
> 2015-10-10T19:35:23.275872-07:00 nohostname kernel: [  152.138819] audit: 
> type=1326 audit(1444530923.273:360): auid=1000 uid=1000 gid=100 ses=1 
> pid=2093 comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c03e 
> syscall=91 compat=0 ip=0x7f92e4bd7ab7 code=0x5
> 2015-10-10T19:35:23.275885-07:00 nohostname kernel: [  152.138937] audit: 
> type=1326 audit(1444530923.274:361): auid=1000 uid=1000 gid=100 ses=1 
> pid=2093 comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c03e 
> syscall=91 compat=0 ip=0x7f92e4bd7ab7 code=0x5
> 2015-10-10T19:35:23.280867-07:00 nohostname kernel: [  152.143147] audit: 
> type=1326 audit(1444530923.279:362): auid=1000 uid=1000 gid=100 ses=1 
> pid=2096 comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c03e 
> syscall=273 compat=0 ip=0x7f92e6168444 code=0x5
> 2015-10-10T19:35:23.282055-07:00 nohostname kernel: [  152.144762] audit: 
> type=1326 audit(1444530923.280:363): auid=1000 uid=1000 gid=100 ses=1 
> pid=2093 comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c03e 
> syscall=2 compat=0 ip=0x7f92eb5f8587 code=0x5
> 2015-10-10T19:35:23.282062-07:00 nohostname kernel: [  152.144890] audit: 
> type=1326 audit(1444530923.280:364): auid=1000 uid=1000 gid=100 ses=1 
> pid=2093 comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c03e 
> syscall=2 compat=0 ip=0x7f92e4b2ac8c code=0x5
> 2015-10-10T19:35:23.282063-07:00 nohostname kernel: [  152.144988] audit: 
> type=1326 audit(1444530923.280:365): auid=1000 uid=1000 gid=100 ses=1 
> pid=2093 comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c03e 
> syscall=2 compat=0 ip=0x7f92e4b2ad70 code=0x5
>
>
> thanks
>
> tony
>
>
> From d6971ec9508244f7a1ab42f9ac4c59b7e1ca6145 Mon Sep 17 00:00:00 2001
> From: Tony Jones 
> Date: Sat, 10 Oct 2015 19:30:49 -0700
> Subject: [PATCH] Don't log seccomp messages when audit is disabled
>
> Don't log seccomp messages when audit is disabled.

This is intentional since violation of a seccomp policy ought to
indicate a misbehaving program, and we want