Provide mechanism to trivially re-enable AF_VSOCK in the default seccomp profile

[gaby]

Maintainer edit: Won't be accepted as is, but alternative mechanisms not involving --cap-add should be supported.

---

Description

Recently several PR's were merged blocking calls to AF_VSOCK. These were backported without warning on a friday as a patch release. This caused a major headache where multiple client systems went down.

There's currently no documentation on how to enable these calls again, or a way give a container the ability to use them unless using priviledge. Forcing users to use a custom seccomp profile as the only way to enable this is not user friendly.

Proposing the addition of a CAP for enabling AF_VSOCK on a container basis.

Example:

docker run -it --cap-add NET_VSOCK alpine:latest

Potential names:

• SYS_VSOCK
• NET_SOCKET
• NET_VSOCK
• VSOCK

Valid use case:

• AF_VSOCK enables networks using Libvirt and KubeVirt to create management tunnels into their Libvirt Domains. For example, we deploy core VM's with a systemd service allowing VSOCK to TCP connection into the local ssh daemon. The domains are running on a segregated network, so the only way to communicate with them is via VSOCK in combination with socat. On the host we dynamically enable these tunnels using socat running inside Docker containers.

Related PR's: #44562 #44563 #44564

Cc. @thaJeztah @AkihiroSuda @GabrielNicolasAvellaneda

[AkihiroSuda]

If this is really expected to be a capability, this should be proposed to the kernel. But getting this accepted in the upstream might be difficult, as the kernel has been already consuming 41 of the total 64 bits.

Perhaps just adding a new seccomp option like --security-opt seccomp=+vsock might suffice?

[AkihiroSuda]

We can also consider defining the "virtual capability" like --cap-add VCAP_NET_VSOCK for controlling the seccomp profile, but that might be rather confusing.

[gaby]

@AkihiroSuda Trying to use --security-opt was my first though. After 10-20mins I realized it had to be backed in into the engine for it to work. The VCAP approach would make sense if there's other functions that could also benefit from having a Virtual Capability assigned to them.

[neersighted]

I strongly object to the concept of a virtual capability -- capabilities in the Linux kernel are well-known and well-defined, and inventing our own is overloading the meaning of the API field and going to create confusion in the ecosystem.

[neersighted]

Also, as there was no update here: This was discussed in the maintainers call. The consensus was no new flags will be added; instead the VSOCK change will be reverted in the 20.10 branch (keep in mind that it is not namespaced so your containers will be able to talk to the Hypervisor Guest Services socket for instance). On 23.0 and newer, it will be blocked by default and you will need to pass a custom seccomp filter if you want to re-allow it.

There are patches upstream that add namespacing to AF_VSOCK, but none have been accepted yet/look likely to land in the next several cycles, so this will likely remain the state of the art for some time.

[gaby]

@neersighted Totally agree, I think the best route is to add a seccomp filter instead of a Virtual Capability.

[neersighted]

Re-opening this; while it will not be implemented as-is, #47663 has me thinking of other ways to answer this ask.

Alternatively, #22109 is more involved but a more holistic way to solve this in the long term.

[gaby]

@neersighted Agree, as of today with v26.x using a custom seccomp is the only way to re-enable VSOCK support.