Open rusty-snake opened 4 years ago
I think whitelists are good idea, especially now that exceptions can be made easily. But I agree that including @default
in @system-service
should 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.
@topimiettinen What do you think on generated the groups systemd-analyze syscall-filter
with a script? Keep the groups from systemd, rename @default to @common and add your own @default* groups.
@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.
Can we omit the #ifdef SYS_XXXX
or would it do bad things?
TODOs:
__dummy_syscall__
src/lib/syscalls_list.c
(or whatever)src/lib/syscalls.c
to #include syscalls_list.c
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.
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.
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 define SYS_XXXX
for 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.
Ping @smitsohu as you're working on syscall definitions.
@rusty-snake Can you open a pull request (or commit right away) ?
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.
@mount
are in@default
.https://github.com/netblue30/firejail/blob/7180f26466a2186ed7b0ccddc7133591feb97518/etc/templates/syscalls.txt#L45
https://github.com/netblue30/firejail/blob/7180f26466a2186ed7b0ccddc7133591feb97518/etc/templates/syscalls.txt#L36
@aio
is in@default
, exceptio_pgetevents
.https://github.com/netblue30/firejail/blob/7180f26466a2186ed7b0ccddc7133591feb97518/etc/templates/syscalls.txt#L30
Line one:
@aio
syscalls in@default
. Line two:@aio
.@sysem-service
should not be used. Why? Let my explain.@sysem-service
is a group forseccomp.keep
and not forseccomp.drop
, therefore it is a whitelisting group (as in systemd).@default
is a blacklisting only group forseccomp.drop
. It includes@obsolete
.@sysem-service
includes@default
and therefore also@obsolete
, since@sysem-service
has so much syscalls that it hardly never will be used forseccomp.drop
. It will be used forseccomp.keep
, but it includes@obsolete
which should never be whitelisted except a program needs all the syscalls from there.https://github.com/netblue30/firejail/blob/7180f26466a2186ed7b0ccddc7133591feb97518/etc/templates/syscalls.txt#L62-L88