whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Some corrections identified by @tallclair. (#12605)

Browse Source
This commit is contained in:
Noah Kantrowitz
2019-02-12 13:54:47 -08:00
committed by Kubernetes Prow Robot
parent d9f5f20600
commit e986ee4cbc
1 changed files with 2 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md
+2 -2
View File
@@ -15,7 +15,7 @@ Kubernetes in turn sits on top of those tools, and so while no part of Kubernete
While full details are still embargoed to give people time to patch, the rough version is that when running a process as root (UID 0) inside a container, that process can exploit a bug in runc to gain root privileges on the host running the container. This then allows them unlimited access to the server as well as any other containers on that server.
If the process inside the container is either trusted (something you know is not hostile) or is not running as UID 0, then the vulnerability does not apply. It can also be prevented by SELinux, if an appropriate policy has been applied. RedHat Enterprise Linux, CentOS, and Fedora all include appropriate SELinux permissions with their packages and so are believed to be unaffected.
If the process inside the container is either trusted (something you know is not hostile) or is not running as UID 0, then the vulnerability does not apply. It can also be prevented by SELinux, if an appropriate policy has been applied. RedHat Enterprise Linux and CentOS both include appropriate SELinux permissions with their packages and so are believed to be unaffected if SELinux is enabled.
The most common source of risk is attacker-controller container images, such as unvetted images from public repositories.
@@ -69,7 +69,7 @@ Some platforms have also posted more specific instructions:
#### Google Container Engine (GKE)
Google has issued a [security bulletin](https://cloud.google.com/kubernetes-engine/docs/security-bulletins#february-11-2019-runc) with more detailed information but in short, if you are using the default GKE node image then you are safe. If you are using an Ubuntu or CoreOS node image then you will need to mitigate or upgrade to an image with a fixed version of runc.
Google has issued a [security bulletin](https://cloud.google.com/kubernetes-engine/docs/security-bulletins#february-11-2019-runc) with more detailed information but in short, if you are using the default GKE node image then you are safe. If you are using an Ubuntu node image then you will need to mitigate or upgrade to an image with a fixed version of runc.
#### Amazon Elastic Container Service for Kubernetes (EKS)