audit.log did not print when --seccomp-error-action is EPERM

[sfc-gh-hyu]

When a system call is violated, and error action is kill, I can see audit.log has an entry indicating the error

sudo ausearch -m SECCOMP --interpret

and

type=SECCOMP msg=audit(07/06/2020 20:17:03.365:18387) : auid=hyu uid=hyu gid=hyu ses=1 pid=9120 comm=<program> sig=SIGSYS arch=x86_64 syscall=stat compat=0 ip=0x7f420b9db5b5 code=kill

However, when the --seccomp-error-action=EPERM, the audit.log did not have an entry.

I also checked

[hyu@DEVVM-hyu trunk]$ cat /proc/sys/kernel/seccomp/actions_logged 
kill trap errno trace

And it seems that errno should be logged. Maybe there is a flag that should be added when configuring seccomp?

[rusty-snake]

This is expected AFAIK.
I wonder for what it is useful. For debugging you can still set it to kill. Are there any drawback when it is not logged?

PR for the kill-> EPERM change: #3301

[sfc-gh-hyu]

I want to use EPERM in production but keep audit logging for audit purpose. Is that possible? Our production environment has some utility which allow me to easily query audit log on each host, so I think it would be nice to have seccomp logging.

[rusty-snake]

Is that possible?

I'm no expert, but I would think it's possible. @topimiettinen can say more.

I want to use EPERM in production but keep audit logging for audit purpose. … Our production environment has some utility which allow me to easily query audit log on each host, so I think it would be nice to have seccomp logging.

I see your point. However, keep in mind that the reason for the change (kill->EPERM) was to block syscalls while allowing the application to continue to work. i.e. audit-logs can be "false-positives", which don't need to be allowed. Which in turn can result in a lot of audit-spam.

[sfc-gh-hyu]

I think this is fine. My usecase is running untrusted user code inside firejail. And need to return a nice user error back when seccomp rule is violated. So application continues runnning just to report error back and stop, which won't spam the audit.log. If you don't want audit logging to be default behavior, is it possible to add an option for that?

[topimiettinen]

You may need to edit auditd configuration to enable logging for failed system calls. Something like this (taken from /etc/audit/rules.d/30-nispom.rules) would log every time open etc. fail with EACCES or EPERM:

-a always,exit -F arch=b32 -S open,openat,open_by_handle_at -F exit=-EACCES -F key=open
-a always,exit -F arch=b64 -S open,openat,open_by_handle_at -F exit=-EACCES -F key=open
-a always,exit -F arch=b32 -S open,openat,open_by_handle_at -F exit=-EPERM -F key=open
-a always,exit -F arch=b64 -S open,openat,open_by_handle_at -F exit=-EPERM -F key=open

But this also means that it also logs every time an unrelated program gets these errors, so logs may fill up quickly.

Maybe you could use instead a rare error code like ENAVAIL ("No XENIX semaphores available", lol) like --seccomp-error-action=ENAVAIL and match that with audit rules instead of EPERM. Though this may confuse applications which may not expect such weird error codes.