[GH-ISSUE #3498] audit.log did not print when --seccomp-error-action is EPERM #2201

Closed
opened 2026-05-05 08:52:58 -06:00 by gitea-mirror · 5 comments
Owner

Originally created by @sfc-gh-hyu on GitHub (Jul 6, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3498

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?

Originally created by @sfc-gh-hyu on GitHub (Jul 6, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3498 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`?
Author
Owner

@rusty-snake commented on GitHub (Jul 7, 2020):

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: https://github.com/netblue30/firejail/pull/3301

<!-- gh-comment-id:654654810 --> @rusty-snake commented on GitHub (Jul 7, 2020): 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: https://github.com/netblue30/firejail/pull/3301
Author
Owner

@sfc-gh-hyu commented on GitHub (Jul 7, 2020):

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.

<!-- gh-comment-id:654879772 --> @sfc-gh-hyu commented on GitHub (Jul 7, 2020): 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.
Author
Owner

@rusty-snake commented on GitHub (Jul 7, 2020):

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.

<!-- gh-comment-id:654892422 --> @rusty-snake commented on GitHub (Jul 7, 2020): > 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.
Author
Owner

@sfc-gh-hyu commented on GitHub (Jul 7, 2020):

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?

<!-- gh-comment-id:655019717 --> @sfc-gh-hyu commented on GitHub (Jul 7, 2020): 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?
Author
Owner

@topimiettinen commented on GitHub (Jul 7, 2020):

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.

<!-- gh-comment-id:655108395 --> @topimiettinen commented on GitHub (Jul 7, 2020): 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.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#2201
No description provided.