Hi,
On 9/20/20 2:03 AM, Finn Thain wrote:
Thorsten Glaser wrote, quoting Aurelien Jarno in https://bugs.debian.org/916276
The 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-seccomp
And 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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)