mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #1] Modify seccomp arguments in profile config for more flexibility #1
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#1
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 @boltronics on GitHub (Aug 9, 2015).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1
At the time of writing, firejail supports:
What I actually want is the default seccomp filter, with some additional system calls on top of the default seccomp filter. Additionally, I might want to remove some system calls in the same profile. To facilitate this functionality, I suggest changing the second seccomp usage option to work like follows:
Regardless of how the information is specified in the profile, it would be very helpful to somehow just say "use the default filter +/- these other system calls". This should cut down the work required for people following the Firejail Seccomp Guide.
@netblue30 commented on GitHub (Aug 11, 2015):
This is exactly what "seccomp syscall,syscall,syscall". It takes the default filter and adds "syscall,syscall,syscall".
I'll leave this open as an enhancement for now.
@boltronics commented on GitHub (Aug 11, 2015):
Sorry - I wasn't very clear. By "with some additional system calls on top of the default seccomp filter", I meant I wanted to allow additional system calls - so effectively it would unblock something the default filter has blocked. I think that's likely to be a more common scenario, as most people would go with the defaults, and then adjust them if they don't work. If they don't work, permissions will need to be relaxed, not tightened.
@netblue30 commented on GitHub (Aug 11, 2015):
I'll have to think about it, thanks.
@netblue30 commented on GitHub (Sep 26, 2015):
I am dropping it. It complicates the code to much.