Hi, On 9/20/20 2:03 AM, Finn Thain wrote:
Thorsten Glaser wrote, quoting Aurelien Jarno in https://bugs.debian.org/916276The patch is basically replacing the getdents64 syscall by the getdents one. This means that applying this patch would make debian differ with regards to other distributions in the syscalls that are used for the same binaries. In turns it is likely going to affect binaries that are using seccomp and only allow the getdents64 and not the getdents one.So upgrading glibc (changing a getdents syscall to a getdents64 syscall) is fine but doing the reverse would "affect binaries that are using seccomp"? Sounds like security theater to me. Do the affected binaries and syscall filters actually exist?
I'm pretty sure this is about containers and seccomp filters attached to them.
AFAIK Docker has seccomp filtering enabled in all the current distros. This lists what it filters by default:
https://docs.docker.com/engine/security/seccomp/Here's the standard OCI bundle specification for controlling it at container level:
https://github.com/opencontainers/runtime-spec/blob/master/config-linux.md#user-content-seccompAnd here's the Kubernetes doc on how to configure it at cluster level (for given service container deployed to the cluster nodes):
https://kubernetes.io/docs/tutorials/clusters/seccomp/Because specifying seccomp filters for containers is so trivial, there are going to be all kind of containers which seccomp rules allow only syscalls they're using _right now_.
I.e. there's big money (large cluster operators) that get irritated when _anything_ changes, unless some balancing improvement can be demonstrated to a majority of users.
- Eero