-
Notifications
You must be signed in to change notification settings - Fork 18.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[20.10] Revert "seccomp: block socket calls to AF_VSOCK in default profile" #44712
Conversation
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?
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
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>
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)
|
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
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
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
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.