ASA-202012-8 - log back

ASA-202012-8 edited at 09 Dec 2020 18:59:34
Workaround
- If you are not providing the ability for untrusted users to start containers in the same network namespace as the shim (typically the "host" network namespace, for example with docker run --net=host or hostNetwork: true in a Kubernetes pod) and run with an effective UID of 0, you are not vulnerable to this issue.
+ If you are not providing the ability for untrusted users to start
+ containers in the same network namespace as the shim (typically the
+ "host" network namespace, for example with docker run --net=host or
+ hostNetwork: true in a Kubernetes pod) and run with an effective UID of
+ 0, you are not vulnerable to this issue.
- If you are running containers with a vulnerable configuration, you can deny access to all abstract sockets with AppArmor by adding a line similar to deny unix addr=@**, to your policy.
+ If you are running containers with a vulnerable configuration, you can
+ deny access to all abstract sockets with AppArmor by adding a line
+ similar to deny unix addr=@**, to your policy.
- It is best practice to run containers with a reduced set of privileges, with a non-zero UID, and with isolated namespaces. The containerd maintainers strongly advise against sharing namespaces with the host. Reducing the set of isolation mechanisms used for a container necessarily increases that container's privilege, regardless of what container runtime is used for running that container.
+ It is best practice to run containers with a reduced set of privileges,
+ with a non-zero UID, and with isolated namespaces. The containerd
+ maintainers strongly advise against sharing namespaces with the host.
+ Reducing the set of isolation mechanisms used for a container
+ necessarily increases that container's privilege, regardless of what
+ container runtime is used for running that container.
ASA-202012-8 edited at 09 Dec 2020 18:40:51
Impact
- A local attacker might be able to escalate privileges via a malicious containers running in the same network namespace as the shim.
+ A local attacker might be able to escalate privileges via a malicious container running in the same network namespace as the shim.
ASA-202012-8 edited at 09 Dec 2020 18:00:08
Impact
+ A local attacker might be able to escalate privileges via a malicious containers running in the same network namespace as the shim.
ASA-202012-8 edited at 09 Dec 2020 17:59:24
Workaround
+ If you are not providing the ability for untrusted users to start containers in the same network namespace as the shim (typically the "host" network namespace, for example with docker run --net=host or hostNetwork: true in a Kubernetes pod) and run with an effective UID of 0, you are not vulnerable to this issue.
+
+ If you are running containers with a vulnerable configuration, you can deny access to all abstract sockets with AppArmor by adding a line similar to deny unix addr=@**, to your policy.
+
+ It is best practice to run containers with a reduced set of privileges, with a non-zero UID, and with isolated namespaces. The containerd maintainers strongly advise against sharing namespaces with the host. Reducing the set of isolation mechanisms used for a container necessarily increases that container's privilege, regardless of what container runtime is used for running that container.
ASA-202012-8 created at 05 Dec 2020 14:30:27