[WIP] Update of syscalls groups

[pierretom]

Hello,

I'm working to update syscalls groups, suggestions or corrections are appreciated.
The following file shows groups with syscalls that will be deleted, moved or added. Other existing syscalls will remain intact and are not present in this file.

new_syscalls_groups_temp.txt

[rusty-snake]

Ref #3106

[rusty-snake]

new_syscalls_groups_temp.txt

• uretprobe: https://lwn.net/Articles/1005662/
• landlock_*: is not @file-system
• memfd_secret: is not @ipc

[pierretom]

For landlock we could go with a sandbox group like systemd:

Yes, good idea.

Regarding memfd_secret: not every syscall must be in a group. For some syscalls it's just fine to be standalone.

Having all syscalls grouped can avoid to forgot to blacklist or whitlist them and make seccomp filters easier to configure.

[rusty-snake]

Having all syscalls grouped can avoid to forgot to blacklist or whitlist them and make seccomp filters easier to configure.

Then add a @secretmem group with one member if you think this is better.

Grouping helps because it bundles related syscalls. But some syscalls do not have any related syscalls.

[pierretom]

Grouping helps because it bundles related syscalls. But some syscalls do not have any related syscalls.

Ok.

• uretprobe: https://lwn.net/Articles/1005662/

I made some tests by blocking uretprobe and no breakages observed. Maybe we can keep it in @debug finally.

[rusty-snake]

But uretprobe is not a debugging syscall in the sense of ptrace/perf_event_open/... (i.e. userspace to kernel request).

Breakage fundamentally depends on the running tracing in your system.

[rusty-snake]

That's are only my two cent. I don't really care because any update to the groups will be an improvement.

[pierretom]

Update 2: new_syscalls_groups_temp2.txt

[netblue30]

Very cool feature! I'll get #6998 merged in in January after the current release, thanks!

[pierretom]

To follow up on the commit 5d78ff5, 2 ideas:

1. Split syscalls in groups
   In @clock, keep syscalls related to system clock modification.
   Create a new group @clock-read or @time-read for syscalls related to time reading.
   Create a new group @sleep or use @timer for syscalls related to sleep functions.
   New groups will be part of @system-service.

2. Move to @default-keep
   Move syscalls from @clock that cause breakages or add new groups to @default-keep.

[netblue30]

Absolutely, go for it! Any other idea you might come up with, just put it in. And don't worry about breaking it, it is quite easy to test and fix.