Limiting SECCOMP audit events

Hello,

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

Also, has anyone verified this sysctl is filtering audit events? Even with the above, I have over a million events on a 4.14.3 kernel. Firefox alone is generating over 50,000 events per hour.

Quoted 12 lines · Steve Grubb

Hello,

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

Quoted 5 lines

kernel.seccomp.actions_logged = kill_process kill_thread errno

Also, has anyone verified this sysctl is filtering audit events? Even with the above, I have over a million events on a 4.14.3 kernel. Firefox alone is generating over 50,000 events per hour.

I don't think you'd want to log errno -- AIUI, that's used regularly by a lot of seccomp policy.

Quoted 15 lines · EST Kees Cook

Quoted 14 lines · Steve Grubb

Hello,

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

Quoted 8 lines

Quoted 5 lines

Also, has anyone verified this sysctl is filtering audit events? Even with
the above, I have over a million events on a 4.14.3 kernel. Firefox alone
is generating over 50,000 events per hour.

I don't think you'd want to log errno -- AIUI, that's used regularly by a lot of seccomp policy.

I'm not seeing any reporting errno. The ones reporting trap are coming in over 50,000 per hour. I don't think the filter is working.

[root@x2 ~]# cat /proc/sys/kernel/seccomp/actions_logged kill_process kill_thread errno
[root@x2 ~]# date
Wed Dec 13 19:24:40 EST 2017
[root@x2 ~]# ausearch --start 19:24:40 -m seccomp --raw | aureport --event --summary -i
Event Summary Report
======================
total type
======================
170 SECCOMP

In the time it took to type the command 170 seccomp events were recorded from firefox.

[root@x2 ~]# ausearch --start 19:24:40 -m seccomp --just-one -i
----
node=x2 type=SECCOMP msg=audit(12/13/2017 19:24:56.454:199666) : auid=sgrubb uid=sgrubb gid=sgrubb ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=3394 comm=Web Content exe=/usr/lib64/firefox/firefox sig=SIG0 arch=x86_64 syscall=stat compat=0 ip=0x7f909c828635 code=trap
^^ trap. With the sheer amount of events being recorded, I think it's necessary to add a sysctl file to systems to suppress the logging. Especially when you consider that systemd-journal also gratuitously grabs audit logs and sends them to rsyslog.

Quoted 43 lines · Steve Grubb

Quoted 15 lines · EST Kees Cook

Quoted 14 lines · Steve Grubb

Hello,

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

Quoted 8 lines

Quoted 5 lines

Also, has anyone verified this sysctl is filtering audit events? Even with
the above, I have over a million events on a 4.14.3 kernel. Firefox alone
is generating over 50,000 events per hour.

I don't think you'd want to log errno -- AIUI, that's used regularly by a lot of seccomp policy.

I'm not seeing any reporting errno. The ones reporting trap are coming in over 50,000 per hour. I don't think the filter is working.

[root@x2 ~]# cat /proc/sys/kernel/seccomp/actions_logged kill_process kill_thread errno
[root@x2 ~]# date
Wed Dec 13 19:24:40 EST 2017
[root@x2 ~]# ausearch --start 19:24:40 -m seccomp --raw | aureport --event --summary -i
Event Summary Report
======================
total type
======================
170 SECCOMP

In the time it took to type the command 170 seccomp events were recorded from firefox.

Quoted 11 lines

[root@x2 ~]# ausearch --start 19:24:40 -m seccomp --just-one -i
----
node=x2 type=SECCOMP msg=audit(12/13/2017 19:24:56.454:199666) :
auid=sgrubb uid=sgrubb gid=sgrubb ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=3394 comm=Web Content exe=/usr/lib64/firefox/firefox sig=SIG0 arch=x86_64 syscall=stat compat=0 ip=0x7f909c828635 code=trap
^^ trap. With the sheer amount of events being recorded, I think it's necessary to add a sysctl file to systems to suppress the logging. Especially when you consider that systemd-journal also gratuitously grabs audit logs and sends them to rsyslog.

Looking at the kernel code, it looks like the actions_logged knob isn't really intended to filter/drop seccomp events,

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.

Quoted 3 lines · EST Paul Moore

Quoted 2 lines · Steve Grubb

Quoted 1 line · EST Kees Cook

On Wed, Dec 13, 2017 at 3:58 PM, Steve Grubb <[email protected]> wrote:

Quoted 2 lines

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.

Quoted 2 lines

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?

Quoted 11 lines

Quoted 2 lines

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.

Quoted 2 lines

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.

Quoted 1 line

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.

Hello,

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

Also, has anyone verified this sysctl is filtering audit events? Even with the above, I have over a million events on a 4.14.3 kernel. Firefox alone is generating over 50,000 events per hour.

Thanks,

-Steve

Quoted 6 lines · Steve Grubb

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

Quoted 5 lines

/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.

Quoted 3 lines

Also, has anyone verified this sysctl is filtering audit events? Even with the above, I have over a million events on a 4.14.3 kernel. Firefox alone is generating over 50,000 events per hour.

Yes. I tested it a lot as the changes were being upstreamed and again when I backported the changes to Ubuntu releases 17.10, 17.04, and 16.04 LTS. Those kernels have been released for a month and a half now and I haven't heard of any issues.

I'll install a Fedora VM and see if I can determine what's happening.

Quoted 25 lines · EST Tyler Hicks

Quoted 21 lines · Steve Grubb

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

Quoted 3 lines

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.

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

include/linux/audit.h +0 -8

index af410d9..095b5dd 100644
@@ -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)
 {

kernel/seccomp.c +0 -0

index 5f0dfb2ab..914a707 100644
@@ -590,12 +590,6 @@ static inline void seccomp_log(unsigned long syscall, long signr, u32 action,
         */
        if (log)

Quoted 28 lines · Steve Grubb

Quoted 25 lines · EST Tyler Hicks

Quoted 21 lines · Steve Grubb

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

Quoted 8 lines

Quoted 3 lines

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

include/linux/audit.h +0 -0

index af410d9..095b5dd 100644

include/linux/audit.h +0 -2

 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)
 {

kernel/seccomp.c +0 -6

index 5f0dfb2ab..914a707 100644
@@ -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
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit

Quoted 88 lines · Tyler Hicks

Quoted 28 lines · Steve Grubb

Quoted 25 lines · EST Tyler Hicks

Quoted 21 lines · Steve Grubb

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

Quoted 8 lines

Quoted 3 lines

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

include/linux/audit.h +0 -0

index af410d9..095b5dd 100644

include/linux/audit.h static inline void audit_inode_child(struct inode *parent, · line 312

Quoted 9 lines

include/linux/audit.h +0 -6

@@ -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.

Quoted 36 lines

include/linux/audit.h +0 -2

 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)
 {

kernel/seccomp.c +0 -6

index 5f0dfb2ab..914a707 100644
@@ -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
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit

Quoted 7 lines

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:

seccomp-log.pseudo +0 -2

@@ -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:

seccomp-log.pseudo +2 -1

@@ -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

On 12/15/2017 08:08 AM, Paul Moore wrote:

Quoted 2 lines

* 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.

Quoted 24 lines · Steve Grubb

Quoted 23 lines · EST Tyler Hicks

Quoted 21 lines · Steve Grubb

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

Quoted 8 lines

Quoted 3 lines

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!

include/linux/audit.h +0 -6

index af410d9..095b5dd 100644
@@ -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)
 {

kernel/seccomp.c +0 -0

index 5f0dfb2ab..914a707 100644
@@ -590,12 +590,6 @@ static inline void seccomp_log(unsigned long syscall,

long signr, u32 action, */

kernel/seccomp.c +0 -6

 	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);
 }
 
 /*

Quoted 50 lines · EST Tyler Hicks

Quoted 15 lines · Steve Grubb

Quoted 14 lines · EST Tyler Hicks

Quoted 13 lines · Steve Grubb

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

Quoted 8 lines

Quoted 5 lines

Quoted 1 line

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

Quoted 6 lines

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.)

Quoted 6 lines

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. :-)

Quoted 4 lines

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.

Quoted 4 lines

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.

Quoted 1 line

I hope this helps!

Thanks!

-Steve

Quoted 45 lines

include/linux/audit.h +0 -6

index af410d9..095b5dd 100644
@@ -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,

include/linux/audit.h +0 -0

 			      struct timespec64 *t, unsigned int *serial)
 
 {

kernel/seccomp.c +0 -0

index 5f0dfb2ab..914a707 100644
@@ -590,12 +590,6 @@ static inline void seccomp_log(unsigned long
 syscall,

long signr, u32 action, */

kernel/seccomp.c static inline void seccomp_log(unsigned long syscall, long signr, u32 action,

Quoted 7 lines

kernel/seccomp.c +0 -3

 	if (log)
 
 		return __audit_seccomp(syscall, signr, action);
 
-
-	/*
-	 * Let the audit subsystem decide if the action should be audited 

kernel/seccomp.c static inline void seccomp_log(unsigned long syscall, long signr, u32 action, · line 595

Quoted 7 lines

kernel/seccomp.c +0 -3

-	 * on whether the current task itself is being audited.
-	 */
-	return audit_seccomp(syscall, signr, action);
 
 }
 
 /*

--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/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

Quoted 176 lines · EST Steve Grubb

Quoted 50 lines · EST Tyler Hicks

Quoted 15 lines · Steve Grubb

Quoted 14 lines · EST Tyler Hicks

Quoted 13 lines · Steve Grubb

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

Quoted 8 lines

Quoted 5 lines

Quoted 1 line

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

Quoted 6 lines

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.)

Quoted 6 lines

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. :-)

Quoted 4 lines

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.

Quoted 4 lines

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.

Quoted 1 line

I hope this helps!

Thanks!

-Steve

Quoted 45 lines

include/linux/audit.h +0 -6

index af410d9..095b5dd 100644
@@ -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,

include/linux/audit.h +0 -0

 			      struct timespec64 *t, unsigned int *serial)
 
 {

kernel/seccomp.c +0 -0

index 5f0dfb2ab..914a707 100644
@@ -590,12 +590,6 @@ static inline void seccomp_log(unsigned long
 syscall,

long signr, u32 action, */

Quoted 7 lines

kernel/seccomp.c static inline void seccomp_log(unsigned long syscall, long signr, u32 action,

Quoted 7 lines

kernel/seccomp.c +0 -3

 	if (log)
 
 		return __audit_seccomp(syscall, signr, action);
 
-
-	/*
-	 * Let the audit subsystem decide if the action should be audited 

based

Quoted 12 lines

kernel/seccomp.c static inline void seccomp_log(unsigned long syscall, long signr, u32 action, · line 595

Quoted 7 lines

kernel/seccomp.c +0 -3

-	 * on whether the current task itself is being audited.
-	 */
-	return audit_seccomp(syscall, signr, action);
 
 }
 
 /*

--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit

Quoted 15 lines · Steve Grubb

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

Quoted 1 line

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

Quoted 16 lines · Tyler Hicks

Quoted 15 lines · Steve Grubb

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

Quoted 8 lines

Quoted 1 line

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.

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?

Quoted 44 lines · Tyler Hicks

Quoted 16 lines · Steve Grubb

Quoted 15 lines

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

Quoted 8 lines

Quoted 1 line

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.

Quoted 4 lines · Steve Grubb

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.

Quoted 50 lines · EDT Paul Moore

Quoted 44 lines · Tyler Hicks

Quoted 16 lines · Steve Grubb

Quoted 15 lines

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

Quoted 8 lines

Quoted 1 line

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.

Quoted 11 lines · Paul Moore

Quoted 4 lines · Steve Grubb

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.