mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #1366] seccomp.keep and seccomp #934
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#934
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 @curiosity-seeker on GitHub (Jul 4, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1366
The seccomp guide is very helpful when creating a list of whitelisted syscalls for a specific program. However, I have a comprehension question regarding
seccomp.keep:seccompblacklists the syscalls in the default list. But when creating a list of whitelisted syscalls it is necessary to add syscalls toseccomp.keepwhich are not explicitly blacklisted byseccomp. But why?Wouldn't it be possible to change the behavior of
seccomp.keepaccordingly? The list(s) of whitelisted syscalls wouldn't be that mile-long anymore, and I think that it would be easier to create new profiles.But perhaps I'm simply missing a decisive argument.
@curiosity-seeker commented on GitHub (Jul 28, 2017):
Modifying the
seccomp.keepbehavior would be really handy. E.g., when I compared the default list withseccomp.keepin my google-chrome profile using thecommutility, I found that only 2 syscalls (chroot and personality) were common in both files. Needless to say that this would make theseccomp.keepline much more overseeable ;-)On the other hand, additional syscalls were recently added to the default list (and this had happened before). This could mean that possibly many profiles that contain
seccomp.keeplines would probably need manual adjustments in order to avoid breakage.Considering this, I'm tempted to withdraw my proposal unless somebody has an idea for a manageable solution.
@ghost commented on GitHub (Jul 28, 2017):
Maybe change behavior of
seccomp.keepandseccomp.droponly ifseccompoption is present?For example if
seccompis present,seccomp.keepwill only whitelist options, which was blocked byseccomp, and withseccomp.dropyou can block additional syscalls without the need to write syscalls from default list. That way there is no need to break old behavior ofseccomp.keepandseccomp.drop.@curiosity-seeker commented on GitHub (Aug 7, 2017):
@netblue30 : You wrote
How exactly would this work now that syscall groups are implemented?
@curiosity-seeker commented on GitHub (Aug 22, 2017):
May I ask again how the syscall groups are helpful in this case?
In the example above concerning google-chrome where only 2 whitelisted syscalls are part of the @default list - how would the existence of those groups help to create a list of whitelisted syscalls?
Sorry, if I might be missing something obvious ....
@topimiettinen commented on GitHub (Aug 22, 2017):
I think the syscall groups are somewhat orthogonal to this feature request, but you may be able to construct the filter you want with the groups more easily than with a long list of syscalls.
With systemd's SystemCallFilter directive it's possible to combine blacklists and whitelists. Maybe something similar could be added.
@chiraag-nataraj commented on GitHub (Jul 22, 2018):
@topimiettinen What do you think the syntax would look like? Something like
seccomp @default-keep,!keyctlwould blacklist everything in@default-keepexceptkeyctlmaybe?@topimiettinen commented on GitHub (Jul 22, 2018):
Something like that, or combinations of multiple lines of
seccomp,seccomp.keepandseccomp.dropcould be allowed.@chiraag-nataraj commented on GitHub (Jul 22, 2018):
@netblue30 What do you think?
@netblue30 commented on GitHub (Jul 24, 2018):
We can go either way:
Or we can even implement both, today a seccomp.keep line is several hundreds chars long.
@chiraag-nataraj commented on GitHub (May 20, 2019):
@netblue30 Have we made any progress on this?
@curiosity-seeker commented on GitHub (May 20, 2019):
@chiraag-nataraj : Thanks for bringing this up again!
Adding to this the issue - mentioned by myself elsewhere - that the syscall groups are nowhere readily defined (I'm sure they are somewhere deep in the source code) so actually using them is rather difficult ...
@Vincent43 commented on GitHub (May 20, 2019):
I recently proposed this elsewhere:
@chiraag-nataraj commented on GitHub (May 20, 2019):
Cool, let's move discussion of this over to #2669.
@Vincent43 commented on GitHub (May 20, 2019):
@chiraag-nataraj actually I think this issue is better focused on seccomp tweaks. The other one could be fixed if we find solution here.
@chiraag-nataraj commented on GitHub (May 20, 2019):
Okay! Let's keep this open then.
@rusty-snake commented on GitHub (Aug 22, 2019):
@curiosity-seeker https://github.com/netblue30/firejail/blob/master/etc/templates/syscalls.txt
@curiosity-seeker commented on GitHub (Aug 23, 2019):
@rusty-snake : Thank you very much! I had noticed it before - very cool, indeed!
@curiosity-seeker commented on GitHub (Aug 23, 2019):
Is there any progress regarding the original issue and the ideas mentioned by @topimiettinen and @chiraag-nataraj ?
@rusty-snake commented on GitHub (Aug 23, 2019):
My Thinking to that ...
seccomp.drop: used to only block listed syscalls (like blacklist for files) -- no changesseccomp.block-secondary: used to block syscalls for other archs -- no changesseccomp.keep: block all syscalls not listed (never used in profiles) -- no changesseccomp: used to block a default list of syscalls (and listed) -- changes wouldn't be break much.@topimiettinen commented on GitHub (Aug 24, 2019):
No progress, but here are further ideas 😃
seccomp.show @default@aio @basic-io @file-system @io-event @ipc @keyring @memlock @network-io @process @signal @sync @system-service @timer. These are mostly unprivileged system calls and thus they could be more useful for user applications than current groups, which contain mostly privileged system calls.@topimiettinen commented on GitHub (Aug 25, 2019):
I've implemented the further systemd groups in PR #2928.