Skip to content

Blocking the socket syscall for AF_VSOCK in the default seccomp profile #7442

@rmohr

Description

@rmohr

What is the problem you're trying to solve

We want to use vsock for guest-host communication on KubeVirt (https://github.com/kubevirt/kubevirt). In KubeVirt we run VMs in pods.

However since anyone can just connect from any pod to any VM with the default seccomp settings, we cannot limit connection attempts to our privileged node-agent.

Describe the solution you'd like

We want to deny the socket syscall for the AF_VSOCK family by default.

I see in [1] and [2] that AF_VSOCK was actually already blocked for some time, but that got reverted since some architectures support the socketcall syscall which can't be restricted properly. However we are mostly intersted in arm64 and amd64 where limiting socket would probably be enough.

[1] moby/moby#29076 (comment)
[2] moby/moby@dcf2632

Additional context

I know that in theory we could use our own seccomp profiles, but we would want to provide security for as many users as possible which use KubeVirt, and there it would be very helpful if this protection could be added by being part of the DefaultRuntime profile to easily ensure that it is active for all pods (https://kubernetes.io/docs/tutorials/security/seccomp/#enable-the-use-of-runtimedefault-as-the-default-seccomp-profile-for-all-workloads).

Impact on existing workloads: It is unlikely that this will disturb any existing workload, becuase VSOCK is almost exclusively used for host-guest commmunication. However if someone would still use it: Privileged pods would still be able to use socket for AF_VSOCK, custom seccomp policies could be applied too. Further it was already blocked for quite some time and the blockade got lifted due to reasons not related to AF_VSOCK.

The PR in KubeVirt which adds VSOCK support for additional context: kubevirt/kubevirt#8546

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions