mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #5207] Flood of seccomp audit log entries #2917
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#2917
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @EdiDD on GitHub (Jun 17, 2022).
Original GitHub issue: https://github.com/netblue30/firejail/issues/5207
There are many log entries like: audit: SECCOMP ... and kernel: audit: ... in journal probably because of (firejail 0.9.70):
Is there a way to disable this or make these messages silently ignored ?
@netblue30 commented on GitHub (Jun 17, 2022):
Bug! I have it on my computer so far for whois, transmission, and Tor browser. Log example:
Syscall 41 is "socket" (you can get the name by running "firejail --debug-syscalls"). In the profile I had to add "netlink" and "unix":
Let's look in the logs for some more programs generating this kind of messages. Thanks for the bug!
@rusty-snake commented on GitHub (Jun 17, 2022):
Previous discussion with suggested fix (and deleted comment 👎): https://github.com/netblue30/firejail/discussions/5181#discussioncomment-2947406
Please link to previous discussion if you move them.
Do we really need to open all this?
@ghost commented on GitHub (Jun 17, 2022):
Personally I tend to agree with @rusty-snake's comment above. It seems overkill to allow a potentially insecure
netlinkprotocol 'just' to keep cleaner logs IMO. Perhaps a comment would be more appropriate instead?Besides, users can always provide their own audit filtering via
/etc/audit/rules.dfor log sanity (audit tends to be very verbose by default). See this for some examples.@netblue30 commented on GitHub (Jun 17, 2022):
Good point! I'll add instead a configuration flag in /etc/firejail/firejail.config to shut down the automatic logging, enabled by default. Will this work?
@ghost commented on GitHub (Jun 17, 2022):
It should work yes. I happen to have some extra time to test if you 'd like. Been doing some specific audit filtering lately in another context, that's why it occurred to me it might be a more appropriate way to deal with this. Once things settle down code-wise I can add a wiki item with some example rules for log sanitation. Thanks for looking into things!
@EdiDD commented on GitHub (Jun 18, 2022):
It also occurs in
curl@netblue30 commented on GitHub (Jun 18, 2022):
I added "seccomp-log no" in /etc/firejail/firejail.config
c7e4c8ed59@EdiDD commented on GitHub (Jun 18, 2022):
Great! , waiting for a patched release. Thank you.
@ghost commented on GitHub (Jun 19, 2022):
@netblue30
c7e4c8ed59works fine, thanks! Just one question: now this is 'fixed', can/should we revert17774ad546?@netblue30 commented on GitHub (Jun 20, 2022):
Forgot about it. I've just revert it.
@kmk3 commented on GitHub (Jun 20, 2022):
@rusty-snake commented on May 20:
@SkewedZeppelin Can this be reverted as well?
@SkewedZeppelin commented on GitHub (Jun 21, 2022):
@kmk3
did