RFE: add SCMP_ACT_DEFAULT rule

[vt-alt]

(Premise: Because seccomp is complicated by design it's useful to give people options to debug and experiment.)
Thus, for example, for a program that have built-in list of syscalls to allow, I want to give user option to list syscalls to deny (via SECCOMP_SYSCALL_DENY env). (This could be used, for another example, if we release first version with a very generic filter but want to let user to check their workflow with some syscall being denied.)

This is suddenly a complicated task for current libseccomp. This is because seccomp_rule_add returns -EACCCES if the rule action equals the default action of the filter.

So it would be nice to have ability to add a rule with default action which then prevents adding rule with other actions.

[pcmoore]

Hi @vt-alt, I want to make sure I understand this feature request; are you asking for the ability to create libseccomp filter rules which take the default action, regardless of what that might be, through the use of a new SCMP_ACT_DEFAULT action?

If that is the request, can you help me understand why this is preferable to simply not creating the rule? The filter should be functionally equivalent either way ...

[vt-alt]

You are correct. This would be equivalent to 1) not adding the rule and 2) the following rules later, but much simpler to the library user. [You already have database of added rules, so the following rules with different action (perhaps already) would return -EEXIST.]

To implement this for library user they need to reimplement rule database ourselves — for the simple reason of allowing end user to skip some syscall from the (allowing) ruleset.

From one point of view this is more like debugging/developing feature. But from other this could be viewed as (letting end user) extending security for example if user wants to forbid key_add if they don't use auth. In a simpler way for libseccomp user.

There is practical example, I am adding rules like simple list of calls to seccomp_rule_add there https://github.com/vt-alt/curl/blob/sisyphus/src/tool_operate.c#L2751

To implement SECCOMP_SYSCALL_DENY (env) with the list of syscalls (like there above is for SECCOMP_SYSCALL_ALLOW) I cannot forbid adding static rules in a simple way. Adding a dummy rules would be conceptually simpler.

[pcmoore]

Thanks for the clarification, I'm still not entirely clear on the advantage this would have over the current approach, but we can leave this RFE issue open for a while to see if there is any additional interest.