mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #3106] seccomp groups (next round) #1945
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#1945
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 @rusty-snake on GitHub (Jan 2, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3106
I was playing with the seccomp filter of my tor-browser setup (https://github.com/rusty-snake/firejailed-tor-browser) and noticed a few things.
@mountare in@default.7180f26466/etc/templates/syscalls.txt (L45)7180f26466/etc/templates/syscalls.txt (L36)@aiois in@default, exceptio_pgetevents.7180f26466/etc/templates/syscalls.txt (L30)Line one:
@aiosyscalls in@default.Line two:
@aio.@sysem-serviceshould not be used. Why? Let my explain.@sysem-serviceis a group forseccomp.keepand not forseccomp.drop, therefore it is a whitelisting group (as in systemd).@defaultis a blacklisting only group forseccomp.drop. It includes@obsolete.@sysem-serviceincludes@defaultand therefore also@obsolete, since@sysem-servicehas so much syscalls that it hardly never will be used forseccomp.drop. It will be used forseccomp.keep, but it includes@obsoletewhich should never be whitelisted except a program needs all the syscalls from there.7180f26466/etc/templates/syscalls.txt (L62-L88)@topimiettinen commented on GitHub (Jan 3, 2020):
I think whitelists are good idea, especially now that exceptions can be made easily. But I agree that including
@defaultin@system-serviceshould be fixed. Maybe a new group could be added which would be designed for whitelisting unprivileged applications.The documentation should perhaps also clarify which groups are mostly useful for blacklists and which for whitelists.
@rusty-snake commented on GitHub (Sep 1, 2020):
@topimiettinen What do you think on generated the groups
systemd-analyze syscall-filterwith a script? Keep the groups from systemd, rename @default to @common and add your own @default* groups.@topimiettinen commented on GitHub (Sep 2, 2020):
@rusty-snake Nice idea, that way we'd be more easily in sync with systemd. That's not a goal stated anywhere, but why differ if there's no need to be different? It would help the users which could be already familiar with either software.
@rusty-snake commented on GitHub (Sep 2, 2020):
Can we omit the
#ifdef SYS_XXXXor would it do bad things?@rusty-snake commented on GitHub (Sep 2, 2020):
current code in syscalls.c
code generated by my script
diff
TODOs:
__dummy_syscall__src/lib/syscalls_list.c(or whatever)src/lib/syscalls.cto#include syscalls_list.c@topimiettinen commented on GitHub (Sep 4, 2020):
Looks great!
__dummy_syscall__is needed because empty system call lists are not allowed, so alternatively that restriction could be relaxed. It would allow dropping some ugly #ifdeffery.@rusty-snake commented on GitHub (Sep 5, 2020):
There is one thing I do not understand. Why do we need the
__dummy_syscall__? It is a invalid syscall, but the other syscall in these groups are also invalid on these platforms.@topimiettinen commented on GitHub (Sep 5, 2020):
Without
__dummy_syscall__, system call groups could become empty if none of the system calls are defined (because they don't exist for an architecture). Empty system call lists are not allowed.Actually I like your suggestion of dropping the
#ifdef SYS_XXXX. We know all Linux system call names and their numbers and it doesn't matter if the libc doesn't defineSYS_XXXXfor some of them, so we could just always use our own definitions and simply ignore non-existent system calls for an architecture later. Then the system call group lists would always be the same and non-empty, so__dummy_syscall__could be removed. A downside would be that x86 groups would be "polluted" with arm groups etc.One problem with copying systemd system call groups mechanically is that systemd uses libseccomp, which doesn't use exactly the same names for all system calls as kernel. It probably doesn't matter much.
@rusty-snake commented on GitHub (Jul 17, 2022):
Ping @smitsohu as you're working on syscall definitions.
@smitsohu commented on GitHub (Jul 19, 2022):
@rusty-snake Can you open a pull request (or commit right away) ?