* Re: Limiting SECCOMP audit events
2017-12-14 23:06 ` Tyler Hicks
@ 2017-12-14 23:16 ` Kees Cook
2017-12-15 14:08 ` Paul Moore
2017-12-15 16:02 ` Steve Grubb
2 siblings, 0 replies; 23+ messages in thread
From: Kees Cook @ 2017-12-14 23:16 UTC (permalink / raw)
To: Tyler Hicks; +Cc: Linux Audit
On Thu, Dec 14, 2017 at 3:06 PM, Tyler Hicks <tyhicks@canonical.com> wrote:
> The reason is because I didn't get clear direction from the audit
> folks about to do when audit is enabled and the process is being audited
> and, therefore, I didn't feel comfortable rocking the boat. In that
> situation, the decision to log is the same as it was in earlier kernels.
> Specifically, you're hitting the last "else if" conditional in the
> pseudocode above.
Yeah, same for me: it's been entirely unclear what the desired
combination of audit vs seccomp should be. It seems like it should be
reporting everything when auditing a specific process, and then ...
something else? ... in the global context.
> If you're happy with having the actions_logged sysctl control whether or
> not to log seccomp actions taken for processes that are being audited,
> then I think the following (untested) patch should do exactly what you
> want. I imagine that you'd also want seccomp to emit audit events
> whenever the value of the actions_logged sysctl is changed, which should
> be pretty easy to do.
>
> I hope this helps!
>
> Tyler
>
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index af410d9..095b5dd 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -304,12 +304,6 @@ static inline void audit_inode_child(struct inode *parent,
> }
> void audit_core_dumps(long signr);
>
> -static inline void audit_seccomp(unsigned long syscall, long signr, int code)
> -{
> - if (audit_enabled && unlikely(!audit_dummy_context()))
> - __audit_seccomp(syscall, signr, code);
> -}
> -
> static inline void audit_ptrace(struct task_struct *t)
> {
> if (unlikely(!audit_dummy_context()))
> @@ -502,8 +496,6 @@ static inline void audit_core_dumps(long signr)
> { }
> static inline void __audit_seccomp(unsigned long syscall, long signr, int code)
> { }
> -static inline void audit_seccomp(unsigned long syscall, long signr, int code)
> -{ }
> static inline int auditsc_get_stamp(struct audit_context *ctx,
> struct timespec64 *t, unsigned int *serial)
> {
> diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> index 5f0dfb2ab..914a707 100644
> --- a/kernel/seccomp.c
> +++ b/kernel/seccomp.c
> @@ -590,12 +590,6 @@ static inline void seccomp_log(unsigned long syscall, long signr, u32 action,
> */
> if (log)
> return __audit_seccomp(syscall, signr, action);
> -
> - /*
> - * Let the audit subsystem decide if the action should be audited based
> - * on whether the current task itself is being audited.
> - */
> - return audit_seccomp(syscall, signr, action);
> }
>
> /*
If audit folks are happy with this, I am too. :)
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Limiting SECCOMP audit events
2017-12-14 23:06 ` Tyler Hicks
2017-12-14 23:16 ` Kees Cook
@ 2017-12-15 14:08 ` Paul Moore
2017-12-15 15:47 ` Tyler Hicks
2017-12-15 16:02 ` Steve Grubb
2 siblings, 1 reply; 23+ messages in thread
From: Paul Moore @ 2017-12-15 14:08 UTC (permalink / raw)
To: Tyler Hicks, Steve Grubb; +Cc: Linux Audit
On December 14, 2017 6:06:49 PM Tyler Hicks <tyhicks@canonical.com> wrote:
> On 12/14/2017 09:19 AM, Steve Grubb wrote:
>> On Thursday, December 14, 2017 10:04:48 AM EST Tyler Hicks wrote:
>>
>>> On 12/13/2017 05:58 PM, Steve Grubb wrote:
>>
>>> > Over the last month, the amount of seccomp events in audit logs is
>>
>>> > sky-rocketing. I have over a million events in the last 2 days. Most of
>>
>>> > this is generated by firefox and qt webkit.
>>
>>> >
>>
>>> > I am wondering if the audit package should ship a file for
>>
>>> >
>>
>>> > /usr/lib/sysctl.d/60-auditd.conf
>>
>>> >
>>
>>> > wherein it has
>>
>>> >
>>
>>> > kernel.seccomp.actions_logged = kill_process kill_thread errno
>>
>>>
>>
>>> I agree with Kees here. IMO, you only want "kill_process kill_thread"
>>
>>> which is the default.
>>
>>
>>
>> The default appears to be all of the types of events without setting
>> kernel.seccomp.actions_logged.
>
> Ah, right. I didn't correctly remember the final implementation details.
> The default sysctl setting is to allow all actions except for RET_ALLOW
> to be logged.
>
> I think the easiest description of the logic is in the commit message of
> 59f5cf44a38284eb9e76270c786fb6cc62ef8ac4:
>
> if action == RET_ALLOW:
> do not log
> else if action == RET_KILL && RET_KILL in actions_logged:
> log
> else if action == RET_LOG && RET_LOG in actions_logged:
> log
> else if filter-requests-logging && action in actions_logged:
> log
> else if audit_enabled && process-is-being-audited:
> log
> else:
> do not log
>
> I think I originally misunderstood your first email in this thread. I
> thought you were saying that you were experiencing more seccomp audit
> events in 4.14 versus 4.13 and that you felt a regression had been
> introduced. After rereading, I think you're asking why you're getting
> seccomp RET_TRAP actions logged even though "trap" isn't in the
> actions_logged sysctl.
>
> The reason is because I didn't get clear direction from the audit
> folks about to do when audit is enabled and the process is being audited
> and, therefore, I didn't feel comfortable rocking the boat. In that
> situation, the decision to log is the same as it was in earlier kernels.
> Specifically, you're hitting the last "else if" conditional in the
> pseudocode above.
>
> If you're happy with having the actions_logged sysctl control whether or
> not to log seccomp actions taken for processes that are being audited,
> then I think the following (untested) patch should do exactly what you
> want. I imagine that you'd also want seccomp to emit audit events
> whenever the value of the actions_logged sysctl is changed, which should
> be pretty easy to do.
>
> I hope this helps!
>
> Tyler
>
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index af410d9..095b5dd 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -304,12 +304,6 @@ static inline void audit_inode_child(struct inode *parent,
> }
> void audit_core_dumps(long signr);
>
> -static inline void audit_seccomp(unsigned long syscall, long signr, int code)
> -{
> - if (audit_enabled && unlikely(!audit_dummy_context()))
> - __audit_seccomp(syscall, signr, code);
> -}
> -
Looks good to me but two things:
* Change the name of __audit_seccomp() to audit_seccomp() since we don't
have two functions anymore.
* Are we sure about removing the audit_enabled check? People got pretty
upset when it wasn't there in the past.
> static inline void audit_ptrace(struct task_struct *t)
> {
> if (unlikely(!audit_dummy_context()))
> @@ -502,8 +496,6 @@ static inline void audit_core_dumps(long signr)
> { }
> static inline void __audit_seccomp(unsigned long syscall, long signr, int code)
> { }
> -static inline void audit_seccomp(unsigned long syscall, long signr, int code)
> -{ }
> static inline int auditsc_get_stamp(struct audit_context *ctx,
> struct timespec64 *t, unsigned int *serial)
> {
> diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> index 5f0dfb2ab..914a707 100644
> --- a/kernel/seccomp.c
> +++ b/kernel/seccomp.c
> @@ -590,12 +590,6 @@ static inline void seccomp_log(unsigned long syscall,
> long signr, u32 action,
> */
> if (log)
> return __audit_seccomp(syscall, signr, action);
> -
> - /*
> - * Let the audit subsystem decide if the action should be audited based
> - * on whether the current task itself is being audited.
> - */
> - return audit_seccomp(syscall, signr, action);
> }
>
> /*
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Limiting SECCOMP audit events
2017-12-15 14:08 ` Paul Moore
@ 2017-12-15 15:47 ` Tyler Hicks
2017-12-15 16:09 ` Steve Grubb
2017-12-15 20:54 ` Paul Moore
0 siblings, 2 replies; 23+ messages in thread
From: Tyler Hicks @ 2017-12-15 15:47 UTC (permalink / raw)
To: Paul Moore, Steve Grubb; +Cc: Linux Audit
[-- Attachment #1.1: Type: text/plain, Size: 6900 bytes --]
On 12/15/2017 08:08 AM, Paul Moore wrote:
> On December 14, 2017 6:06:49 PM Tyler Hicks <tyhicks@canonical.com> wrote:
>
>> On 12/14/2017 09:19 AM, Steve Grubb wrote:
>>> On Thursday, December 14, 2017 10:04:48 AM EST Tyler Hicks wrote:
>>>
>>>> On 12/13/2017 05:58 PM, Steve Grubb wrote:
>>>
>>>>> Over the last month, the amount of seccomp events in audit logs is
>>>
>>>>> sky-rocketing. I have over a million events in the last 2 days. Most of
>>>
>>>>> this is generated by firefox and qt webkit.
>>>
>>>>>
>>>
>>>>> I am wondering if the audit package should ship a file for
>>>
>>>>>
>>>
>>>>> /usr/lib/sysctl.d/60-auditd.conf
>>>
>>>>>
>>>
>>>>> wherein it has
>>>
>>>>>
>>>
>>>>> kernel.seccomp.actions_logged = kill_process kill_thread errno
>>>
>>>>
>>>
>>>> I agree with Kees here. IMO, you only want "kill_process kill_thread"
>>>
>>>> which is the default.
>>>
>>>
>>>
>>> The default appears to be all of the types of events without setting
>>> kernel.seccomp.actions_logged.
>>
>> Ah, right. I didn't correctly remember the final implementation details.
>> The default sysctl setting is to allow all actions except for RET_ALLOW
>> to be logged.
>>
>> I think the easiest description of the logic is in the commit message of
>> 59f5cf44a38284eb9e76270c786fb6cc62ef8ac4:
>>
>> if action == RET_ALLOW:
>> do not log
>> else if action == RET_KILL && RET_KILL in actions_logged:
>> log
>> else if action == RET_LOG && RET_LOG in actions_logged:
>> log
>> else if filter-requests-logging && action in actions_logged:
>> log
>> else if audit_enabled && process-is-being-audited:
>> log
>> else:
>> do not log
>>
>> I think I originally misunderstood your first email in this thread. I
>> thought you were saying that you were experiencing more seccomp audit
>> events in 4.14 versus 4.13 and that you felt a regression had been
>> introduced. After rereading, I think you're asking why you're getting
>> seccomp RET_TRAP actions logged even though "trap" isn't in the
>> actions_logged sysctl.
>>
>> The reason is because I didn't get clear direction from the audit
>> folks about to do when audit is enabled and the process is being audited
>> and, therefore, I didn't feel comfortable rocking the boat. In that
>> situation, the decision to log is the same as it was in earlier kernels.
>> Specifically, you're hitting the last "else if" conditional in the
>> pseudocode above.
>>
>> If you're happy with having the actions_logged sysctl control whether or
>> not to log seccomp actions taken for processes that are being audited,
>> then I think the following (untested) patch should do exactly what you
>> want. I imagine that you'd also want seccomp to emit audit events
>> whenever the value of the actions_logged sysctl is changed, which should
>> be pretty easy to do.
>>
>> I hope this helps!
>>
>> Tyler
>>
>> diff --git a/include/linux/audit.h b/include/linux/audit.h
>> index af410d9..095b5dd 100644
>> --- a/include/linux/audit.h
>> +++ b/include/linux/audit.h
>> @@ -304,12 +304,6 @@ static inline void audit_inode_child(struct inode *parent,
>> }
>> void audit_core_dumps(long signr);
>>
>> -static inline void audit_seccomp(unsigned long syscall, long signr, int code)
>> -{
>> - if (audit_enabled && unlikely(!audit_dummy_context()))
>> - __audit_seccomp(syscall, signr, code);
>> -}
>> -
>
> Looks good to me but two things:
>
> * Change the name of __audit_seccomp() to audit_seccomp() since we don't
> have two functions anymore.
>
> * Are we sure about removing the audit_enabled check? People got pretty
> upset when it wasn't there in the past.
Do you have any references to the complaints so that we can understand
them better? I remember being surprised by commit 96368701 adding the
audit_enabled check (my fault for not watching the list closer) and
having to revert it in Ubuntu with a distro patch.
After sleeping on it for a night, I'm now unsure if the patch I sent in
this thread is what you guys really want. I'll go back to talking in
pseudocode. This is what we have in 4.14:
if action == RET_ALLOW:
do not log
else if action == RET_KILL && RET_KILL in actions_logged:
log
else if action == RET_LOG && RET_LOG in actions_logged:
log
else if filter-requests-logging && action in actions_logged:
log
else if audit_enabled && process-is-being-audited:
log
else:
do not log
This is what the patch in this thread does:
--- a/seccomp-log.pseudo
+++ b/seccomp-log.pseudo
@@ -6,7 +6,5 @@
log
else if filter-requests-logging && action in actions_logged:
log
- else if audit_enabled && process-is-being-audited:
- log
else:
do not log
Instead of that change, now I'm wondering if this is what you really
want:
--- a/seccomp-log.pseudo
+++ b/seccomp-log.pseudo
@@ -6,7 +6,8 @@
log
else if filter-requests-logging && action in actions_logged:
log
- else if audit_enabled && process-is-being-audited:
+ else if audit_enabled && process-is-being-audited &&
+ action in actions_logged:
log
else:
do not log
After refactoring the 'action in actions_logged' check, it would leave
us with this:
if action == RET_ALLOW:
do not log
else if action not in actions_logged:
do not log
else if action == RET_KILL:
log
else if action == RET_LOG:
log
else if filter-requests-logging:
log
else if audit_enabled && process-is-being-audited:
log
else:
do not log
Tyler
>
>> static inline void audit_ptrace(struct task_struct *t)
>> {
>> if (unlikely(!audit_dummy_context()))
>> @@ -502,8 +496,6 @@ static inline void audit_core_dumps(long signr)
>> { }
>> static inline void __audit_seccomp(unsigned long syscall, long signr, int code)
>> { }
>> -static inline void audit_seccomp(unsigned long syscall, long signr, int code)
>> -{ }
>> static inline int auditsc_get_stamp(struct audit_context *ctx,
>> struct timespec64 *t, unsigned int *serial)
>> {
>> diff --git a/kernel/seccomp.c b/kernel/seccomp.c
>> index 5f0dfb2ab..914a707 100644
>> --- a/kernel/seccomp.c
>> +++ b/kernel/seccomp.c
>> @@ -590,12 +590,6 @@ static inline void seccomp_log(unsigned long syscall,
>> long signr, u32 action,
>> */
>> if (log)
>> return __audit_seccomp(syscall, signr, action);
>> -
>> - /*
>> - * Let the audit subsystem decide if the action should be audited based
>> - * on whether the current task itself is being audited.
>> - */
>> - return audit_seccomp(syscall, signr, action);
>> }
>>
>> /*
>>
>> --
>> Linux-audit mailing list
>> Linux-audit@redhat.com
>> https://www.redhat.com/mailman/listinfo/linux-audit
>
>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Limiting SECCOMP audit events
2017-12-15 15:47 ` Tyler Hicks
@ 2017-12-15 16:09 ` Steve Grubb
2017-12-15 20:54 ` Paul Moore
1 sibling, 0 replies; 23+ messages in thread
From: Steve Grubb @ 2017-12-15 16:09 UTC (permalink / raw)
To: Tyler Hicks; +Cc: Linux Audit
On Friday, December 15, 2017 10:47:14 AM EST Tyler Hicks wrote:
> > Looks good to me but two things:
> >
> > * Change the name of __audit_seccomp() to audit_seccomp() since we don't
> > have two functions anymore.
> >
> > * Are we sure about removing the audit_enabled check? People got pretty
> > upset when it wasn't there in the past.
>
> Do you have any references to the complaints so that we can understand
> them better? I remember being surprised by commit 96368701 adding the
> audit_enabled check (my fault for not watching the list closer) and
> having to revert it in Ubuntu with a distro patch.
>
>
> After sleeping on it for a night, I'm now unsure if the patch I sent in
> this thread is what you guys really want. I'll go back to talking in
> pseudocode. This is what we have in 4.14:
>
> if action == RET_ALLOW:
> do not log
> else if action == RET_KILL && RET_KILL in actions_logged:
> log
> else if action == RET_LOG && RET_LOG in actions_logged:
> log
> else if filter-requests-logging && action in actions_logged:
> log
> else if audit_enabled && process-is-being-audited:
> log
> else:
> do not log
>
> This is what the patch in this thread does:
>
> --- a/seccomp-log.pseudo
> +++ b/seccomp-log.pseudo
> @@ -6,7 +6,5 @@
> log
> else if filter-requests-logging && action in actions_logged:
> log
> - else if audit_enabled && process-is-being-audited:
> - log
> else:
> do not log
>
> Instead of that change, now I'm wondering if this is what you really
> want:
>
> --- a/seccomp-log.pseudo
> +++ b/seccomp-log.pseudo
> @@ -6,7 +6,8 @@
> log
> else if filter-requests-logging && action in actions_logged:
> log
> - else if audit_enabled && process-is-being-audited:
> + else if audit_enabled && process-is-being-audited &&
> + action in actions_logged:
> log
> else:
> do not log
>
> After refactoring the 'action in actions_logged' check, it would leave
> us with this:
>
> if action == RET_ALLOW:
> do not log
> else if action not in actions_logged:
> do not log
Yeah, this would let us drop the trap return. While errno can lead to a lot of
logging, in practice I just don't see them very often if ever.
-Steve
> else if action == RET_KILL:
> log
> else if action == RET_LOG:
> log
> else if filter-requests-logging:
> log
> else if audit_enabled && process-is-being-audited:
> log
> else:
> do not log
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Limiting SECCOMP audit events
2017-12-15 15:47 ` Tyler Hicks
2017-12-15 16:09 ` Steve Grubb
@ 2017-12-15 20:54 ` Paul Moore
1 sibling, 0 replies; 23+ messages in thread
From: Paul Moore @ 2017-12-15 20:54 UTC (permalink / raw)
To: Tyler Hicks, Steve Grubb; +Cc: Linux Audit
On December 15, 2017 10:47:17 AM Tyler Hicks <tyhicks@canonical.com> wrote:
> On 12/15/2017 08:08 AM, Paul Moore wrote:
...
>> * Are we sure about removing the audit_enabled check? People got pretty
>> upset when it wasn't there in the past.
>
> Do you have any references to the complaints so that we can understand
> them better? I remember being surprised by commit 96368701 adding the
> audit_enabled check (my fault for not watching the list closer) and
> having to revert it in Ubuntu with a distro patch.
I'm somewhat limited at the moment (replying by phone) so I can't my find
it for you, but check the audit mailing list for the discussion.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Limiting SECCOMP audit events
2017-12-14 23:06 ` Tyler Hicks
2017-12-14 23:16 ` Kees Cook
2017-12-15 14:08 ` Paul Moore
@ 2017-12-15 16:02 ` Steve Grubb
2018-01-02 20:03 ` Steve Grubb
2 siblings, 1 reply; 23+ messages in thread
From: Steve Grubb @ 2017-12-15 16:02 UTC (permalink / raw)
To: Tyler Hicks; +Cc: Linux Audit
On Thursday, December 14, 2017 6:06:30 PM EST Tyler Hicks wrote:
> On 12/14/2017 09:19 AM, Steve Grubb wrote:
> > On Thursday, December 14, 2017 10:04:48 AM EST Tyler Hicks wrote:
> >> On 12/13/2017 05:58 PM, Steve Grubb wrote:
> >> > Over the last month, the amount of seccomp events in audit logs is
> >> >
> >> > sky-rocketing. I have over a million events in the last 2 days. Most of
> >> >
> >> > this is generated by firefox and qt webkit.
> >> >
> >> >
> >> >
> >> > I am wondering if the audit package should ship a file for
> >> >
> >> >
> >> >
> >> > /usr/lib/sysctl.d/60-auditd.conf
> >> >
> >> >
> >> >
> >> > wherein it has
> >> >
> >> >
> >> >
> >> > kernel.seccomp.actions_logged = kill_process kill_thread errno
> >>
> >> I agree with Kees here. IMO, you only want "kill_process kill_thread"
> >>
> >> which is the default.
> >
> >
> >
> > The default appears to be all of the types of events without setting
> > kernel.seccomp.actions_logged.
>
> Ah, right. I didn't correctly remember the final implementation details.
> The default sysctl setting is to allow all actions except for RET_ALLOW
> to be logged.
>
> I think the easiest description of the logic is in the commit message of
> 59f5cf44a38284eb9e76270c786fb6cc62ef8ac4:
>
> if action == RET_ALLOW:
> do not log
> else if action == RET_KILL && RET_KILL in actions_logged:
> log
> else if action == RET_LOG && RET_LOG in actions_logged:
> log
> else if filter-requests-logging && action in actions_logged:
> log
> else if audit_enabled && process-is-being-audited:
> log
> else:
> do not log
>
> I think I originally misunderstood your first email in this thread. I
> thought you were saying that you were experiencing more seccomp audit
> events in 4.14 versus 4.13 and that you felt a regression had been
> introduced. After rereading, I think you're asking why you're getting
> seccomp RET_TRAP actions logged even though "trap" isn't in the
> actions_logged sysctl.
Yes, exactly. I have been experiencing large amounts of SECCOMP events
starting with qt webkit in kde and thought 4.14 would finally let me tame
those events. I have opened a couple bz asking developers if they really meant
to go live with a policy that is experiencing so many denials. But the
consensus is this is intended. (But I think they also have not actually tried
to use their audit logs.)
> The reason is because I didn't get clear direction from the audit
> folks about to do when audit is enabled and the process is being audited
> and, therefore, I didn't feel comfortable rocking the boat. In that
> situation, the decision to log is the same as it was in earlier kernels.
> Specifically, you're hitting the last "else if" conditional in the
> pseudocode above.
And here I thought you were also seeing large numbers of seccomp events and
were making a way to control what gets logged. In any event, I think we better
understand each other now. :-)
> If you're happy with having the actions_logged sysctl control whether or
> not to log seccomp actions taken for processes that are being audited,
> then I think the following (untested) patch should do exactly what you
> want.
OK. Great. With developers starting to use the trap return value, audit logs
are getting swamped by benign events. We truly need a knob to eliminate the
noise from the signal.
> I imagine that you'd also want seccomp to emit audit events whenever the
> value of the actions_logged sysctl is changed, which should be pretty easy
> to do.
Sure. If you want to add it, then it should be roughly like this:
struct tty_struct *tty;
const struct cred *cred;
struct audit_buffer *ab;
char comm[sizeof(current->comm)];
ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_CONFIG_CHANGE);
if (unlikely(!ab))
return;
cred = current_cred();
tty = audit_get_tty(current);
audit_log_format(ab, "pid=%d uid=%u auid=%u tty=%s ses=%u",
task_tgid_nr(current),
from_kuid(&init_user_ns, cred->uid),
from_kuid(&init_user_ns,
audit_get_loginuid(current)),
tty ? tty_name(tty) : "(none)",
audit_get_sessionid(current));
audit_put_tty(tty);
audit_log_task_context(ab);
audit_log_format(ab, " comm=");
audit_log_untrustedstring(ab, get_task_comm(comm, current));
audit_log_d_path_exe(ab, current->mm);
audit_log_format(ab, "op=seccomp-logging");
<You can log the new value here if you wish - just can't have spaces in the
value. Numbers or mask is fine.>
audit_log_format(ab, " res=%u", res);
where res above is a 1 for success and 0 for failure. Failure is likely to be
due to not having the capability that allows setting the sysctl.
> I hope this helps!
Thanks!
-Steve
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index af410d9..095b5dd 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -304,12 +304,6 @@ static inline void audit_inode_child(struct inode
> *parent, }
> void audit_core_dumps(long signr);
>
> -static inline void audit_seccomp(unsigned long syscall, long signr, int
> code) -{
> - if (audit_enabled && unlikely(!audit_dummy_context()))
> - __audit_seccomp(syscall, signr, code);
> -}
> -
> static inline void audit_ptrace(struct task_struct *t)
> {
> if (unlikely(!audit_dummy_context()))
> @@ -502,8 +496,6 @@ static inline void audit_core_dumps(long signr)
> { }
> static inline void __audit_seccomp(unsigned long syscall, long signr, int
> code) { }
> -static inline void audit_seccomp(unsigned long syscall, long signr, int
> code) -{ }
> static inline int auditsc_get_stamp(struct audit_context *ctx,
> struct timespec64 *t, unsigned int *serial)
> {
> diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> index 5f0dfb2ab..914a707 100644
> --- a/kernel/seccomp.c
> +++ b/kernel/seccomp.c
> @@ -590,12 +590,6 @@ static inline void seccomp_log(unsigned long syscall,
> long signr, u32 action, */
> if (log)
> return __audit_seccomp(syscall, signr, action);
> -
> - /*
> - * Let the audit subsystem decide if the action should be audited based
> - * on whether the current task itself is being audited.
> - */
> - return audit_seccomp(syscall, signr, action);
> }
>
> /*
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Limiting SECCOMP audit events
2017-12-15 16:02 ` Steve Grubb
@ 2018-01-02 20:03 ` Steve Grubb
2018-01-03 2:52 ` Tyler Hicks
0 siblings, 1 reply; 23+ messages in thread
From: Steve Grubb @ 2018-01-02 20:03 UTC (permalink / raw)
To: linux-audit
Hello,
I know people have been busy with the holidays and things...but I just wanted
to mention I'm still seeing 100's of thousands of seccomp events hitting the
audit logs every day.
# ausearch --start today -m seccomp --raw | aureport -x --summary
Executable Summary Report
=================================
total file
=================================
209843 /usr/lib64/firefox/firefox
2196 /usr/lib64/qt5/libexec/QtWebEngineProcess
Has anyone looked at it beyond pseudo code?
-Steve
On Friday, December 15, 2017 11:02:19 AM EST Steve Grubb wrote:
> On Thursday, December 14, 2017 6:06:30 PM EST Tyler Hicks wrote:
> > On 12/14/2017 09:19 AM, Steve Grubb wrote:
> > > On Thursday, December 14, 2017 10:04:48 AM EST Tyler Hicks wrote:
> > >> On 12/13/2017 05:58 PM, Steve Grubb wrote:
> > >> > Over the last month, the amount of seccomp events in audit logs is
> > >> >
> > >> > sky-rocketing. I have over a million events in the last 2 days. Most
> > >> > of
> > >> >
> > >> > this is generated by firefox and qt webkit.
> > >> >
> > >> > I am wondering if the audit package should ship a file for
> > >> >
> > >> > /usr/lib/sysctl.d/60-auditd.conf
> > >> >
> > >> > wherein it has
> > >> >
> > >> > kernel.seccomp.actions_logged = kill_process kill_thread errno
> > >>
> > >> I agree with Kees here. IMO, you only want "kill_process kill_thread"
> > >>
> > >> which is the default.
> > >
> > > The default appears to be all of the types of events without setting
> > > kernel.seccomp.actions_logged.
> >
> > Ah, right. I didn't correctly remember the final implementation details.
> > The default sysctl setting is to allow all actions except for RET_ALLOW
> > to be logged.
> >
> > I think the easiest description of the logic is in the commit message of
> >
> > 59f5cf44a38284eb9e76270c786fb6cc62ef8ac4:
> > if action == RET_ALLOW:
> > do not log
> >
> > else if action == RET_KILL && RET_KILL in actions_logged:
> > log
> >
> > else if action == RET_LOG && RET_LOG in actions_logged:
> > log
> >
> > else if filter-requests-logging && action in actions_logged:
> > log
> >
> > else if audit_enabled && process-is-being-audited:
> > log
> >
> > else:
> > do not log
> >
> > I think I originally misunderstood your first email in this thread. I
> > thought you were saying that you were experiencing more seccomp audit
> > events in 4.14 versus 4.13 and that you felt a regression had been
> > introduced. After rereading, I think you're asking why you're getting
> > seccomp RET_TRAP actions logged even though "trap" isn't in the
> > actions_logged sysctl.
>
> Yes, exactly. I have been experiencing large amounts of SECCOMP events
> starting with qt webkit in kde and thought 4.14 would finally let me tame
> those events. I have opened a couple bz asking developers if they really
> meant to go live with a policy that is experiencing so many denials. But
> the consensus is this is intended. (But I think they also have not
> actually tried to use their audit logs.)
>
> > The reason is because I didn't get clear direction from the audit
> > folks about to do when audit is enabled and the process is being audited
> > and, therefore, I didn't feel comfortable rocking the boat. In that
> > situation, the decision to log is the same as it was in earlier kernels.
> > Specifically, you're hitting the last "else if" conditional in the
> > pseudocode above.
>
> And here I thought you were also seeing large numbers of seccomp events and
> were making a way to control what gets logged. In any event, I think we
> better understand each other now. :-)
>
> > If you're happy with having the actions_logged sysctl control whether or
> > not to log seccomp actions taken for processes that are being audited,
> > then I think the following (untested) patch should do exactly what you
> > want.
>
> OK. Great. With developers starting to use the trap return value, audit
> logs are getting swamped by benign events. We truly need a knob to
> eliminate the noise from the signal.
>
> > I imagine that you'd also want seccomp to emit audit events whenever the
> > value of the actions_logged sysctl is changed, which should be pretty
> > easy
> > to do.
>
> Sure. If you want to add it, then it should be roughly like this:
>
> struct tty_struct *tty;
> const struct cred *cred;
> struct audit_buffer *ab;
> char comm[sizeof(current->comm)];
>
> ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_CONFIG_CHANGE);
> if (unlikely(!ab))
> return;
>
> cred = current_cred();
> tty = audit_get_tty(current);
> audit_log_format(ab, "pid=%d uid=%u auid=%u tty=%s ses=%u",
> task_tgid_nr(current),
> from_kuid(&init_user_ns, cred->uid),
> from_kuid(&init_user_ns,
> audit_get_loginuid(current)),
> tty ? tty_name(tty) : "(none)",
> audit_get_sessionid(current));
> audit_put_tty(tty);
> audit_log_task_context(ab);
> audit_log_format(ab, " comm=");
> audit_log_untrustedstring(ab, get_task_comm(comm, current));
> audit_log_d_path_exe(ab, current->mm);
> audit_log_format(ab, "op=seccomp-logging");
>
> <You can log the new value here if you wish - just can't have spaces in the
> value. Numbers or mask is fine.>
>
> audit_log_format(ab, " res=%u", res);
>
> where res above is a 1 for success and 0 for failure. Failure is likely to
> be due to not having the capability that allows setting the sysctl.
>
> > I hope this helps!
>
> Thanks!
>
> -Steve
>
> > diff --git a/include/linux/audit.h b/include/linux/audit.h
> > index af410d9..095b5dd 100644
> > --- a/include/linux/audit.h
> > +++ b/include/linux/audit.h
> > @@ -304,12 +304,6 @@ static inline void audit_inode_child(struct inode
> > *parent, }
> >
> > void audit_core_dumps(long signr);
> >
> > -static inline void audit_seccomp(unsigned long syscall, long signr, int
> > code) -{
> > - if (audit_enabled && unlikely(!audit_dummy_context()))
> > - __audit_seccomp(syscall, signr, code);
> > -}
> > -
> >
> > static inline void audit_ptrace(struct task_struct *t)
> > {
> >
> > if (unlikely(!audit_dummy_context()))
> >
> > @@ -502,8 +496,6 @@ static inline void audit_core_dumps(long signr)
> >
> > { }
> > static inline void __audit_seccomp(unsigned long syscall, long signr,
> > int
> >
> > code) { }
> > -static inline void audit_seccomp(unsigned long syscall, long signr, int
> > code) -{ }
> >
> > static inline int auditsc_get_stamp(struct audit_context *ctx,
> >
> > struct timespec64 *t, unsigned int *serial)
> >
> > {
> >
> > diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> > index 5f0dfb2ab..914a707 100644
> > --- a/kernel/seccomp.c
> > +++ b/kernel/seccomp.c
> > @@ -590,12 +590,6 @@ static inline void seccomp_log(unsigned long
> > syscall,
> > long signr, u32 action, */
> >
> > if (log)
> >
> > return __audit_seccomp(syscall, signr, action);
> >
> > -
> > - /*
> > - * Let the audit subsystem decide if the action should be audited
based
> > - * on whether the current task itself is being audited.
> > - */
> > - return audit_seccomp(syscall, signr, action);
> >
> > }
> >
> > /*
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Limiting SECCOMP audit events
2018-01-02 20:03 ` Steve Grubb
@ 2018-01-03 2:52 ` Tyler Hicks
2018-01-03 14:25 ` Paul Moore
0 siblings, 1 reply; 23+ messages in thread
From: Tyler Hicks @ 2018-01-03 2:52 UTC (permalink / raw)
To: Steve Grubb, linux-audit
[-- Attachment #1.1.1: Type: text/plain, Size: 8196 bytes --]
On 01/02/2018 02:03 PM, Steve Grubb wrote:
> Hello,
>
> I know people have been busy with the holidays and things...but I just wanted
> to mention I'm still seeing 100's of thousands of seccomp events hitting the
> audit logs every day.
>
> # ausearch --start today -m seccomp --raw | aureport -x --summary
>
> Executable Summary Report
> =================================
> total file
> =================================
> 209843 /usr/lib64/firefox/firefox
> 2196 /usr/lib64/qt5/libexec/QtWebEngineProcess
>
> Has anyone looked at it beyond pseudo code?
I started to throw together a quick couple of patches prior to the
holidays but didn't finish. Things aren't looking good for the next few
weeks for me so someone else should take over if it is important for 4.16.
Tyler
>
> -Steve
>
> On Friday, December 15, 2017 11:02:19 AM EST Steve Grubb wrote:
>> On Thursday, December 14, 2017 6:06:30 PM EST Tyler Hicks wrote:
>>> On 12/14/2017 09:19 AM, Steve Grubb wrote:
>>>> On Thursday, December 14, 2017 10:04:48 AM EST Tyler Hicks wrote:
>>>>> On 12/13/2017 05:58 PM, Steve Grubb wrote:
>>>>>> Over the last month, the amount of seccomp events in audit logs is
>>>>>>
>>>>>> sky-rocketing. I have over a million events in the last 2 days. Most
>>>>>> of
>>>>>>
>>>>>> this is generated by firefox and qt webkit.
>>>>>>
>>>>>> I am wondering if the audit package should ship a file for
>>>>>>
>>>>>> /usr/lib/sysctl.d/60-auditd.conf
>>>>>>
>>>>>> wherein it has
>>>>>>
>>>>>> kernel.seccomp.actions_logged = kill_process kill_thread errno
>>>>>
>>>>> I agree with Kees here. IMO, you only want "kill_process kill_thread"
>>>>>
>>>>> which is the default.
>>>>
>>>> The default appears to be all of the types of events without setting
>>>> kernel.seccomp.actions_logged.
>>>
>>> Ah, right. I didn't correctly remember the final implementation details.
>>> The default sysctl setting is to allow all actions except for RET_ALLOW
>>> to be logged.
>>>
>>> I think the easiest description of the logic is in the commit message of
>>>
>>> 59f5cf44a38284eb9e76270c786fb6cc62ef8ac4:
>>> if action == RET_ALLOW:
>>> do not log
>>>
>>> else if action == RET_KILL && RET_KILL in actions_logged:
>>> log
>>>
>>> else if action == RET_LOG && RET_LOG in actions_logged:
>>> log
>>>
>>> else if filter-requests-logging && action in actions_logged:
>>> log
>>>
>>> else if audit_enabled && process-is-being-audited:
>>> log
>>>
>>> else:
>>> do not log
>>>
>>> I think I originally misunderstood your first email in this thread. I
>>> thought you were saying that you were experiencing more seccomp audit
>>> events in 4.14 versus 4.13 and that you felt a regression had been
>>> introduced. After rereading, I think you're asking why you're getting
>>> seccomp RET_TRAP actions logged even though "trap" isn't in the
>>> actions_logged sysctl.
>>
>> Yes, exactly. I have been experiencing large amounts of SECCOMP events
>> starting with qt webkit in kde and thought 4.14 would finally let me tame
>> those events. I have opened a couple bz asking developers if they really
>> meant to go live with a policy that is experiencing so many denials. But
>> the consensus is this is intended. (But I think they also have not
>> actually tried to use their audit logs.)
>>
>>> The reason is because I didn't get clear direction from the audit
>>> folks about to do when audit is enabled and the process is being audited
>>> and, therefore, I didn't feel comfortable rocking the boat. In that
>>> situation, the decision to log is the same as it was in earlier kernels.
>>> Specifically, you're hitting the last "else if" conditional in the
>>> pseudocode above.
>>
>> And here I thought you were also seeing large numbers of seccomp events and
>> were making a way to control what gets logged. In any event, I think we
>> better understand each other now. :-)
>>
>>> If you're happy with having the actions_logged sysctl control whether or
>>> not to log seccomp actions taken for processes that are being audited,
>>> then I think the following (untested) patch should do exactly what you
>>> want.
>>
>> OK. Great. With developers starting to use the trap return value, audit
>> logs are getting swamped by benign events. We truly need a knob to
>> eliminate the noise from the signal.
>>
>>> I imagine that you'd also want seccomp to emit audit events whenever the
>>> value of the actions_logged sysctl is changed, which should be pretty
>>> easy
>>> to do.
>>
>> Sure. If you want to add it, then it should be roughly like this:
>>
>> struct tty_struct *tty;
>> const struct cred *cred;
>> struct audit_buffer *ab;
>> char comm[sizeof(current->comm)];
>>
>> ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_CONFIG_CHANGE);
>> if (unlikely(!ab))
>> return;
>>
>> cred = current_cred();
>> tty = audit_get_tty(current);
>> audit_log_format(ab, "pid=%d uid=%u auid=%u tty=%s ses=%u",
>> task_tgid_nr(current),
>> from_kuid(&init_user_ns, cred->uid),
>> from_kuid(&init_user_ns,
>> audit_get_loginuid(current)),
>> tty ? tty_name(tty) : "(none)",
>> audit_get_sessionid(current));
>> audit_put_tty(tty);
>> audit_log_task_context(ab);
>> audit_log_format(ab, " comm=");
>> audit_log_untrustedstring(ab, get_task_comm(comm, current));
>> audit_log_d_path_exe(ab, current->mm);
>> audit_log_format(ab, "op=seccomp-logging");
>>
>> <You can log the new value here if you wish - just can't have spaces in the
>> value. Numbers or mask is fine.>
>>
>> audit_log_format(ab, " res=%u", res);
>>
>> where res above is a 1 for success and 0 for failure. Failure is likely to
>> be due to not having the capability that allows setting the sysctl.
>>
>>> I hope this helps!
>>
>> Thanks!
>>
>> -Steve
>>
>>> diff --git a/include/linux/audit.h b/include/linux/audit.h
>>> index af410d9..095b5dd 100644
>>> --- a/include/linux/audit.h
>>> +++ b/include/linux/audit.h
>>> @@ -304,12 +304,6 @@ static inline void audit_inode_child(struct inode
>>> *parent, }
>>>
>>> void audit_core_dumps(long signr);
>>>
>>> -static inline void audit_seccomp(unsigned long syscall, long signr, int
>>> code) -{
>>> - if (audit_enabled && unlikely(!audit_dummy_context()))
>>> - __audit_seccomp(syscall, signr, code);
>>> -}
>>> -
>>>
>>> static inline void audit_ptrace(struct task_struct *t)
>>> {
>>>
>>> if (unlikely(!audit_dummy_context()))
>>>
>>> @@ -502,8 +496,6 @@ static inline void audit_core_dumps(long signr)
>>>
>>> { }
>>> static inline void __audit_seccomp(unsigned long syscall, long signr,
>>> int
>>>
>>> code) { }
>>> -static inline void audit_seccomp(unsigned long syscall, long signr, int
>>> code) -{ }
>>>
>>> static inline int auditsc_get_stamp(struct audit_context *ctx,
>>>
>>> struct timespec64 *t, unsigned int *serial)
>>>
>>> {
>>>
>>> diff --git a/kernel/seccomp.c b/kernel/seccomp.c
>>> index 5f0dfb2ab..914a707 100644
>>> --- a/kernel/seccomp.c
>>> +++ b/kernel/seccomp.c
>>> @@ -590,12 +590,6 @@ static inline void seccomp_log(unsigned long
>>> syscall,
>>> long signr, u32 action, */
>>>
>>> if (log)
>>>
>>> return __audit_seccomp(syscall, signr, action);
>>>
>>> -
>>> - /*
>>> - * Let the audit subsystem decide if the action should be audited
> based
>>> - * on whether the current task itself is being audited.
>>> - */
>>> - return audit_seccomp(syscall, signr, action);
>>>
>>> }
>>>
>>> /*
>>
>> --
>> Linux-audit mailing list
>> Linux-audit@redhat.com
>> https://www.redhat.com/mailman/listinfo/linux-audit
>
>
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Limiting SECCOMP audit events
2018-01-03 2:52 ` Tyler Hicks
@ 2018-01-03 14:25 ` Paul Moore
2018-04-17 22:54 ` Steve Grubb
0 siblings, 1 reply; 23+ messages in thread
From: Paul Moore @ 2018-01-03 14:25 UTC (permalink / raw)
To: Tyler Hicks, Steve Grubb; +Cc: linux-audit
On Tue, Jan 2, 2018 at 9:52 PM, Tyler Hicks <tyhicks@canonical.com> wrote:
> On 01/02/2018 02:03 PM, Steve Grubb wrote:
>> Hello,
>>
>> I know people have been busy with the holidays and things...but I just wanted
>> to mention I'm still seeing 100's of thousands of seccomp events hitting the
>> audit logs every day.
>>
>> # ausearch --start today -m seccomp --raw | aureport -x --summary
>>
>> Executable Summary Report
>> =================================
>> total file
>> =================================
>> 209843 /usr/lib64/firefox/firefox
>> 2196 /usr/lib64/qt5/libexec/QtWebEngineProcess
>>
>> Has anyone looked at it beyond pseudo code?
>
> I started to throw together a quick couple of patches prior to the
> holidays but didn't finish. Things aren't looking good for the next few
> weeks for me so someone else should take over if it is important for 4.16.
>
> Tyler
This is also on my todo list, but it sits behind fixing one last
libseccomp bug and getting a new release out. I made some good
progress on the libseccomp bug right before the holiday, but I think
there is still a days worth of work left before it is ready to be
merged. I'm also traveling for the next week so I doubt I'll have any
serious time to devote to the kernel patch(es).
I can't remember what Tyler's last thought was on the logic, but I
imagine I'll just wait until I see some patches to review/merge, or I
can go back in the thread if I happen to have time before anyone else.
Also, to set expectations, since we are currently at -rc6, this is
likely going to need to wait until 4.17 at the earliest as I generally
don't like merging new functionality in the last week or two before
the merge window.
Also (part two), we should add a test case to the audit-testsuite for
any new knobs that affect the SECCOMP records.
--
paul moore
www.paul-moore.com
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Limiting SECCOMP audit events
2018-01-03 14:25 ` Paul Moore
@ 2018-04-17 22:54 ` Steve Grubb
2018-04-18 1:57 ` Paul Moore
0 siblings, 1 reply; 23+ messages in thread
From: Steve Grubb @ 2018-04-17 22:54 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit
Hello,
Ping? SECCOMP events are still flooding the system. Can we do something
hackish to turn this off until a better solution can be created?
Thanks,
-Steve
On Wednesday, January 3, 2018 9:25:12 AM EDT Paul Moore wrote:
> On Tue, Jan 2, 2018 at 9:52 PM, Tyler Hicks <tyhicks@canonical.com> wrote:
> > On 01/02/2018 02:03 PM, Steve Grubb wrote:
> >> Hello,
> >>
> >> I know people have been busy with the holidays and things...but I just
> >> wanted to mention I'm still seeing 100's of thousands of seccomp events
> >> hitting the audit logs every day.
> >>
> >> # ausearch --start today -m seccomp --raw | aureport -x --summary
> >>
> >> Executable Summary Report
> >> =================================
> >> total file
> >> =================================
> >> 209843 /usr/lib64/firefox/firefox
> >> 2196 /usr/lib64/qt5/libexec/QtWebEngineProcess
> >>
> >> Has anyone looked at it beyond pseudo code?
> >
> > I started to throw together a quick couple of patches prior to the
> > holidays but didn't finish. Things aren't looking good for the next few
> > weeks for me so someone else should take over if it is important for
> > 4.16.
> >
> > Tyler
>
> This is also on my todo list, but it sits behind fixing one last
> libseccomp bug and getting a new release out. I made some good
> progress on the libseccomp bug right before the holiday, but I think
> there is still a days worth of work left before it is ready to be
> merged. I'm also traveling for the next week so I doubt I'll have any
> serious time to devote to the kernel patch(es).
>
> I can't remember what Tyler's last thought was on the logic, but I
> imagine I'll just wait until I see some patches to review/merge, or I
> can go back in the thread if I happen to have time before anyone else.
>
> Also, to set expectations, since we are currently at -rc6, this is
> likely going to need to wait until 4.17 at the earliest as I generally
> don't like merging new functionality in the last week or two before
> the merge window.
>
> Also (part two), we should add a test case to the audit-testsuite for
> any new knobs that affect the SECCOMP records.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Limiting SECCOMP audit events
2018-04-17 22:54 ` Steve Grubb
@ 2018-04-18 1:57 ` Paul Moore
2018-04-25 0:00 ` Tyler Hicks
0 siblings, 1 reply; 23+ messages in thread
From: Paul Moore @ 2018-04-18 1:57 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
On Tue, Apr 17, 2018 at 6:54 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> Hello,
>
> Ping? SECCOMP events are still flooding the system. Can we do something
> hackish to turn this off until a better solution can be created?
Pong?
The only workarounds I can think of would be to disable audit or
create a filter rule excluding auditing for the noisy process. I've
never tried the latter, but I'm pretty sure it would work.
> On Wednesday, January 3, 2018 9:25:12 AM EDT Paul Moore wrote:
>> On Tue, Jan 2, 2018 at 9:52 PM, Tyler Hicks <tyhicks@canonical.com> wrote:
>> > On 01/02/2018 02:03 PM, Steve Grubb wrote:
>> >> Hello,
>> >>
>> >> I know people have been busy with the holidays and things...but I just
>> >> wanted to mention I'm still seeing 100's of thousands of seccomp events
>> >> hitting the audit logs every day.
>> >>
>> >> # ausearch --start today -m seccomp --raw | aureport -x --summary
>> >>
>> >> Executable Summary Report
>> >> =================================
>> >> total file
>> >> =================================
>> >> 209843 /usr/lib64/firefox/firefox
>> >> 2196 /usr/lib64/qt5/libexec/QtWebEngineProcess
>> >>
>> >> Has anyone looked at it beyond pseudo code?
>> >
>> > I started to throw together a quick couple of patches prior to the
>> > holidays but didn't finish. Things aren't looking good for the next few
>> > weeks for me so someone else should take over if it is important for
>> > 4.16.
>> >
>> > Tyler
>>
>> This is also on my todo list, but it sits behind fixing one last
>> libseccomp bug and getting a new release out. I made some good
>> progress on the libseccomp bug right before the holiday, but I think
>> there is still a days worth of work left before it is ready to be
>> merged. I'm also traveling for the next week so I doubt I'll have any
>> serious time to devote to the kernel patch(es).
>>
>> I can't remember what Tyler's last thought was on the logic, but I
>> imagine I'll just wait until I see some patches to review/merge, or I
>> can go back in the thread if I happen to have time before anyone else.
>>
>> Also, to set expectations, since we are currently at -rc6, this is
>> likely going to need to wait until 4.17 at the earliest as I generally
>> don't like merging new functionality in the last week or two before
>> the merge window.
>>
>> Also (part two), we should add a test case to the audit-testsuite for
>> any new knobs that affect the SECCOMP records.
>
>
>
>
--
paul moore
www.paul-moore.com
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Limiting SECCOMP audit events
2018-04-18 1:57 ` Paul Moore
@ 2018-04-25 0:00 ` Tyler Hicks
2018-04-26 14:41 ` Paul Moore
0 siblings, 1 reply; 23+ messages in thread
From: Tyler Hicks @ 2018-04-25 0:00 UTC (permalink / raw)
To: Paul Moore, Steve Grubb; +Cc: linux-audit
[-- Attachment #1.1.1: Type: text/plain, Size: 3898 bytes --]
On 04/17/2018 08:57 PM, Paul Moore wrote:
> On Tue, Apr 17, 2018 at 6:54 PM, Steve Grubb <sgrubb@redhat.com> wrote:
>> Hello,
>>
>> Ping? SECCOMP events are still flooding the system. Can we do something
>> hackish to turn this off until a better solution can be created?
>
> Pong?
>
> The only workarounds I can think of would be to disable audit or
> create a filter rule excluding auditing for the noisy process. I've
> never tried the latter, but I'm pretty sure it would work.
I've pushed two branches which have slightly different behaviors. They
only differ by the last patch in each branch. The tree is here:
https://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/linux.git/
1) seccomp-auditing/option-1-consistent-behavior
This branch removes all special casing around audited processes. The
decision on whether or not to audit an action no longer considers
whether or not the process is being audited. RET_TRAP, RET_TRACE,
and RET_ERRNO actions will only be logged if the application loads
the filter with the SECCOMP_FILTER_FLAG_LOG bit set. The admin has
the final say via the kernel.seccomp.actions_logged sysctl.
2) seccomp-auditing/option-2-honor-sysctl
This branch continues to special case audited processes. The decision
to log RET_TRAP, RET_TRACE, and RET_ERRNO actions depends on if the
SECCOMP_FILTER_FLAG_LOG bit being set OR if the process is being
audited. The admin has the final say via the
kernel.seccomp.actions_logged sysctl.
I prefer option #1. Play with both implementations and let me know what
works best for your requirements. Both branches share the same
underlying patches for emitting audit records on writes to the
kernel.seccomp.actions_logged sysctl.
Tyler
>
>> On Wednesday, January 3, 2018 9:25:12 AM EDT Paul Moore wrote:
>>> On Tue, Jan 2, 2018 at 9:52 PM, Tyler Hicks <tyhicks@canonical.com> wrote:
>>>> On 01/02/2018 02:03 PM, Steve Grubb wrote:
>>>>> Hello,
>>>>>
>>>>> I know people have been busy with the holidays and things...but I just
>>>>> wanted to mention I'm still seeing 100's of thousands of seccomp events
>>>>> hitting the audit logs every day.
>>>>>
>>>>> # ausearch --start today -m seccomp --raw | aureport -x --summary
>>>>>
>>>>> Executable Summary Report
>>>>> =================================
>>>>> total file
>>>>> =================================
>>>>> 209843 /usr/lib64/firefox/firefox
>>>>> 2196 /usr/lib64/qt5/libexec/QtWebEngineProcess
>>>>>
>>>>> Has anyone looked at it beyond pseudo code?
>>>>
>>>> I started to throw together a quick couple of patches prior to the
>>>> holidays but didn't finish. Things aren't looking good for the next few
>>>> weeks for me so someone else should take over if it is important for
>>>> 4.16.
>>>>
>>>> Tyler
>>>
>>> This is also on my todo list, but it sits behind fixing one last
>>> libseccomp bug and getting a new release out. I made some good
>>> progress on the libseccomp bug right before the holiday, but I think
>>> there is still a days worth of work left before it is ready to be
>>> merged. I'm also traveling for the next week so I doubt I'll have any
>>> serious time to devote to the kernel patch(es).
>>>
>>> I can't remember what Tyler's last thought was on the logic, but I
>>> imagine I'll just wait until I see some patches to review/merge, or I
>>> can go back in the thread if I happen to have time before anyone else.
>>>
>>> Also, to set expectations, since we are currently at -rc6, this is
>>> likely going to need to wait until 4.17 at the earliest as I generally
>>> don't like merging new functionality in the last week or two before
>>> the merge window.
>>>
>>> Also (part two), we should add a test case to the audit-testsuite for
>>> any new knobs that affect the SECCOMP records.
>>
>>
>>
>>
>
>
>
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Limiting SECCOMP audit events
2018-04-25 0:00 ` Tyler Hicks
@ 2018-04-26 14:41 ` Paul Moore
0 siblings, 0 replies; 23+ messages in thread
From: Paul Moore @ 2018-04-26 14:41 UTC (permalink / raw)
To: Tyler Hicks; +Cc: linux-audit
On Tue, Apr 24, 2018 at 8:00 PM, Tyler Hicks <tyhicks@canonical.com> wrote:
> On 04/17/2018 08:57 PM, Paul Moore wrote:
>> On Tue, Apr 17, 2018 at 6:54 PM, Steve Grubb <sgrubb@redhat.com> wrote:
>>> Hello,
>>>
>>> Ping? SECCOMP events are still flooding the system. Can we do something
>>> hackish to turn this off until a better solution can be created?
>>
>> Pong?
>>
>> The only workarounds I can think of would be to disable audit or
>> create a filter rule excluding auditing for the noisy process. I've
>> never tried the latter, but I'm pretty sure it would work.
>
> I've pushed two branches which have slightly different behaviors. They
> only differ by the last patch in each branch. The tree is here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/linux.git/
>
> 1) seccomp-auditing/option-1-consistent-behavior
> This branch removes all special casing around audited processes. The
> decision on whether or not to audit an action no longer considers
> whether or not the process is being audited. RET_TRAP, RET_TRACE,
> and RET_ERRNO actions will only be logged if the application loads
> the filter with the SECCOMP_FILTER_FLAG_LOG bit set. The admin has
> the final say via the kernel.seccomp.actions_logged sysctl.
>
> 2) seccomp-auditing/option-2-honor-sysctl
> This branch continues to special case audited processes. The decision
> to log RET_TRAP, RET_TRACE, and RET_ERRNO actions depends on if the
> SECCOMP_FILTER_FLAG_LOG bit being set OR if the process is being
> audited. The admin has the final say via the
> kernel.seccomp.actions_logged sysctl.
>
> I prefer option #1. Play with both implementations and let me know what
> works best for your requirements. Both branches share the same
> underlying patches for emitting audit records on writes to the
> kernel.seccomp.actions_logged sysctl.
Looking quickly at the two branches, I think I prefer the
option-1-consistent-behavior approach, although some changes are
needed. Could you post those patches to list for review/discussion?
--
paul moore
www.paul-moore.com
^ permalink raw reply [flat|nested] 23+ messages in thread