Firejail: seccomp.keep and seccomp

[curiosity-seeker]

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:

seccomp blacklists the syscalls in the default list. But when creating a list of whitelisted syscalls it is necessary to add syscalls to seccomp.keep which are not explicitly blacklisted by seccomp. But why?

Wouldn't it be possible to change the behavior of seccomp.keep accordingly? 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]

Modifying the seccomp.keep behavior would be really handy. E.g., when I compared the default list with seccomp.keep in my google-chrome profile using the comm utility, I found that only 2 syscalls (chroot and personality) were common in both files. Needless to say that this would make the seccomp.keep line 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.keep lines 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.

[Svadkos]

Maybe change behavior of seccomp.keep and seccomp.drop only if seccomp option is present?

For example if seccomp is present, seccomp.keep will only whitelist options, which was blocked by seccomp, and with seccomp.dropyou can block additional syscalls without the need to write syscalls from default list. That way there is no need to break old behavior of seccomp.keep and seccomp.drop.

[curiosity-seeker]

@netblue30 : You wrote

@default list will also close #1366

How exactly would this work now that syscall groups are implemented?

[curiosity-seeker]

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]

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]

@topimiettinen What do you think the syntax would look like? Something like seccomp @default-keep,!keyctl would blacklist everything in @default-keep _except_ keyctl maybe?

[topimiettinen]

Something like that, or combinations of multiple lines of seccomp, seccomp.keep and seccomp.drop could be allowed.

[chiraag-nataraj]

@netblue30 What do you think?

[netblue30]

We can go either way:

1. seccomp @default-keep,!keyctl
2. multiple lines of seccomp, seccomp.keep and seccomp.drop

Or we can even implement both, today a seccomp.keep line is several hundreds chars long.

[chiraag-nataraj]

@netblue30 Have we made any progress on this?

[curiosity-seeker]

@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]

I recently proposed this elsewhere:

Maybe tweak seccomp rule to allow defining firejail defaults +/- a chosen syscall,
like seccomp +chroot?

[chiraag-nataraj]

Cool, let's move discussion of this over to #2669.

[Vincent43]

@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]

Okay! Let's keep this open then.

[rusty-snake]

that the syscall groups are nowhere readily defined

@curiosity-seeker https://github.com/netblue30/firejail/blob/master/etc/templates/syscalls.txt

[curiosity-seeker]

@rusty-snake : Thank you very much! I had noticed it before - very cool, indeed!

[curiosity-seeker]

Is there any progress regarding the original issue and the ideas mentioned by @topimiettinen and @chiraag-nataraj ?

[rusty-snake]

My Thinking to that ...

seccomp.drop: used to only block listed syscalls (like blacklist for files) -- no changes
seccomp.block-secondary: used to block syscalls for other archs -- no changes
seccomp.keep: block all syscalls not listed (never used in profiles) -- no changes
seccomp: used to block a default list of syscalls (and listed) -- changes wouldn't be break much.

[topimiettinen]

No progress, but here are further ideas :smiley:

• command line option to discover seccomp groups: seccomp.show @default
• copy further system call group ideas from systemd: @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]

I've implemented the further systemd groups in PR #2928.