seccomp rule for NETLINK_AUDIT is ignored on S390X

[alexandrevicenzi]

Hi,

I would like to discuss the following rule which blocks socket(AF_NETLINK, SOCK_RAW, NETLINK_AUDIT).

This rule has been introduced by https://github.com/seccomp/containers-golang/commit/f318ea962a1228ea9f6a2825b0051b2144699a16, to my understanding as a workaround for not having CAP_AUDIT_WRITE or perhaps this PR https://github.com/containers/common/pull/1240.

Returning EINVAL in most applications, in theory, will not break execution, while EPERM would cause certain applications to exit with "Permission denied".

One good example is opessh-server, which handles both errors differently, EPERM results in a connection close, while EINVAL ignores audit and results in a connection being made.

We, however, found a corner case, where the rule can be completely ignored if the system is using socketcall. This syscall is old and has been replaced by proper ones such as socket, but if glibc is compiled to be compatible with an older kernel (e.g. SLE/openSUSE), at least on S390X, instead of socket you get a call to socketcall bypassing this seccomp rule.

My questions are:

1. Is this EINVAL rule necessary? There's no guarantee that all applications will work if there's no CAP_AUDIT_WRITE, the application might fail, and this EINVAL will cause some head scratches and cost some debug time, while "Permission denied" is often a lot clear what is going on.
2. Should this EINVAL also be applied to socketcall to keep behavior identical regardless of syscalls?
3. Is there a strong reason to be strict on CAP_AUDIT_WRITE?