[20.10] Revert "seccomp: block socket calls to AF_VSOCK in default profile" #44712
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Still no idea why we sometimes run into this; for some reason it tries to use device mapper in a test in a situation where it's not supported? |
This reverts commit 57b2290. This change, while favorable from a security standpoint, caused a regression for users of the 20.10 branch of Moby. As such, we are reverting it to ensure stability and compatibility for the affected users. However, users of AF_VSOCK in containers should recognize that this (special) address family is not currently namespaced in any version of the Linux kernel, and may result in unexpected behavior, like VMs communicating directly with host hypervisors. Future branches, including the 23.0 branch, will continue to filter AF_VSOCK. Users who need to allow containers to communicate over the unnamespaced AF_VSOCK will need to turn off seccomp confinement or set a custom seccomp profile. It is our hope that future mechanisms will make this more ergonomic/maintainable for end users, and that future kernels will support namespacing of AF_VSOCK. Signed-off-by: Bjorn Neergaard <bneergaard@mirantis.com>
neersighted
force-pushed
the
20.10_revert_vsock_filter
branch
from
0a1c28a
to
dcf27af
Compare
|
Pushed a version that drops a bad whitespace change that failed validation. |
|
Failure on Windows is unrelated, and a known flaky test (#38521) |
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As discussed in last week's maintainer call. Closes #44670.
This reverts commit 57b2290.
This change, while favorable from a security standpoint, caused a
regression for users of the 20.10 branch of Moby. As such, we are
reverting it to ensure stability and compatibility for the affected
users.
However, users of AF_VSOCK in containers should recognize that this
(special) address family is not currently namespaced in any version of
the Linux kernel, and may result in unexpected behavior, like VMs
communicating directly with host hypervisors.
Future branches, including the 23.0 branch, will continue to filter
AF_VSOCK. Users who need to allow containers to communicate over the
unnamespaced AF_VSOCK will need to turn off seccomp confinement or set a
custom seccomp profile.
It is our hope that future mechanisms will make this more
ergonomic/maintainable for end users, and that future kernels will
support namespacing of AF_VSOCK.