Skip to content

[23.0 backport] seccomp: block socket calls to AF_VSOCK in default profile#44563

Merged
thaJeztah merged 1 commit into
moby:23.0from
thaJeztah:23.0_backport_seccomp_block_af_vsock
Dec 1, 2022
Merged

[23.0 backport] seccomp: block socket calls to AF_VSOCK in default profile#44563
thaJeztah merged 1 commit into
moby:23.0from
thaJeztah:23.0_backport_seccomp_block_af_vsock

Conversation

@thaJeztah

Copy link
Copy Markdown
Member

backport:

related:

This syncs the seccomp-profile with the latest changes in containerd's profile, applying the same changes as containerd/containerd@17a9324

Some background from the associated ticket:

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 interested
in arm64 and amd64 where limiting socket would probably be enough.

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 3.

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: 4

- Description for the changelog

- seccomp: AF_VSOCK is not blocked by default in the default profile

- A picture of a cute animal (not mandatory but encouraged)

This syncs the seccomp-profile with the latest changes in containerd's
profile, applying the same changes as containerd/containerd@17a9324

Some background from the associated ticket:

> 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 interested
> in `arm64` and `amd64` where limiting `socket` would probably be enough.
>
> ### 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 [3].
>
> 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: [4]
>
> [1]: moby#29076 (comment)
> [2]: moby@dcf2632
> [3]: https://kubernetes.io/docs/tutorials/security/seccomp/#enable-the-use-of-runtimedefault-as-the-default-seccomp-profile-for-all-workloads
> [4]: kubevirt/kubevirt#8546

Signed-off-by: Sebastiaan van Stijn <[email protected]>
(cherry picked from commit 57b2290)
Signed-off-by: Sebastiaan van Stijn <[email protected]>
@thaJeztah

Copy link
Copy Markdown
Member Author

/cc @gabriellavengeo

@thaJeztah
thaJeztah merged commit b21e8f7 into moby:23.0 Dec 1, 2022
@thaJeztah
thaJeztah deleted the 23.0_backport_seccomp_block_af_vsock branch December 1, 2022 20:39
thomlinton added a commit to PSU-OIT-ARC/oregoninvasiveshotline that referenced this pull request Nov 1, 2023
Refs: PSU-OIT-ARC/oregon-registry-online@5b7a642

It appears that there are strange interactions when running uWSGI with
the python-auto-reload option on Docker Engine 23.

When code changes are detected and the worker(s) are reloaded, traffic
between the proxy and application container appears to hang and the
processes representing the application containers continue to consume
100% of CPU resources.

Superficially, it appears this issue is related to seccomp changes
released in Docker Engine 23 and backported to Docker Engine 20 (though
subsequenctly reverted).

Refs: https://stackoverflow.com/questions/75511524/nginxuwsgi-stops-responding-after-auto-reload
Refs: https://docs.docker.com/engine/release-notes/23.0/
Refs: moby/moby#44563
Refs: moby/moby#44712
thomlinton added a commit to PSU-OIT-ARC/aol-backend that referenced this pull request Jan 25, 2024
It appears that there are strange interactions when running uWSGI with
the python-auto-reload option on Docker Engine 23.

When code changes are detected and the worker(s) are reloaded, traffic
between the proxy and application container appears to hang and the
processes representing the application containers continue to consume
100% of CPU resources.

Superficially, it appears this issue is related to seccomp changes
released in Docker Engine 23 and backported to Docker Engine 20 (though
subsequenctly reverted).

Refs: https://stackoverflow.com/questions/75511524/nginxuwsgi-stops-responding-after-auto-reload
Refs: https://docs.docker.com/engine/release-notes/23.0/
Refs: moby/moby#44563
Refs: moby/moby#44712
thomlinton added a commit to PSU-OIT-ARC/oregoninvasiveshotline that referenced this pull request Feb 7, 2024
It appears that there are strange interactions when running uWSGI with
the python-auto-reload option on Docker Engine 23.

When code changes are detected and the worker(s) are reloaded, traffic
between the proxy and application container appears to hang and the
processes representing the application containers continue to consume
100% of CPU resources.

Superficially, it appears this issue is related to seccomp changes
released in Docker Engine 23 and backported to Docker Engine 20 (though
subsequenctly reverted).

Refs: https://stackoverflow.com/questions/75511524/nginxuwsgi-stops-responding-after-auto-reload
Refs: https://docs.docker.com/engine/release-notes/23.0/
Refs: moby/moby#44563
Refs: moby/moby#44712
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants