Kubernetes中CVE-2019-11244漏洞怎么修复
这篇文章将为大家详细讲解有关Kubernetes中CVE-2019-11244漏洞怎么修复，小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。
背景知识
为了能更好的理解这个漏洞，需要一些关于Linux 文件权限的基础知识。
也许你经常使用chmod命令来为某个文件设置权限，比如给某个文件设置权限：chmod 755 xxx。这里755为十进制数字分别代表文件Owner权限、文件Owner同组用户权限和其他用户权限，如下图所示：
在Linux下，使用ls命令可以看到文件的权限，如下图所示：
针对一个文件设置权限无非就是限制文件的读、写和可执行权限，那么如何理解一个目录的读、写和可执行权限呢？ 跟据我小范围调查，大多数人不能很好的回答这个问题：一个用户对某个目录拥有读或写权限分别意味着什么？
漏洞描述
CVE-2019-11244漏洞原文描述如下：
In Kubernetes v1.8.x-v1.14.x, schema info is cached by kubectl in the location specified by --cache-dir (defaulting to $HOME/.kube/http-cache), written with world-writeable permissions (rw-rw-rw-). If --cache-dir is specified and pointed at a different location accessible to other users/groups, the written files may be modified by other users/groups and disrupt the kubectl invocation.
简单的理解就是kubectl创建的缓存文件权限为rw-rw-rw-，也即666，这些缓存文件有被其他用户修改的风险。
这里其他用户是包含两类：
同group下的其他用户（后面称group用户）；
不同group的其他用户（后面称other用户）；
那么修复这个漏洞，就要收缩这些文件权限，只要做到这些文件不能被这两类用户修改即可（可以拥有读权限）。
社区修复方案
kubectl会创建一个专门的目录来存放缓存文件，所以这里既要控制目录权限还要控制文件的权限。
在社区的修复方案中，缓存目录权限由755变成了750，即other用户将不能进入这个目录，Group用户仍拥有r-x权限，即可以读取目录下的文件列表、可以进入该目录。
针对缓存文件的修改，权限由755变成了660，这里有三个变化：
Owner用户不再拥有可执行权限（缓存文件拥有可执行文件权限本身也没有意义）；
Group用户拥有
rw-权限，即Group用户仍然可以修改缓存文件；Other用户不授予任何权限（即便有权限也无效，因为上层目录已不能访问）；
看到这里，问题就清楚了，缓存文件仍然可以被Group用户修改，实际上漏洞并没有完全修复。 我们可以实际操作演示一下，这里如无特别说明表示使用root用户操作：
创建一个目录，并设置权限为755:
# mkdir -m 0750 myPath0750在目录中创建一个文件，并设置权限为660：
# touch myPath0750/myFile0660; chmod 0660 myPath0750/myFile0660创建一个root组用户，并设置密码：
# useradd -G root -d /home/horen -m horen; passwd horen切换到新用户，尝试修改文件内容：
# echo "Hello" > myPath0750/myFile0660；
可以发现文件是可以被修改的。
加固方案
也许社区的修复方案并不能满足你的安全要求，你仍然需要基于社区方案做一些安全加固，就是把缓存文件的权限进一步收缩，由660变为640，即Group用户最多只能查看缓存文件内容。
另外，由于目录权限为750，Group用户对该目录没有写权限，所以不能修改目录名，不能在该目录下创建文件，达到目录专用的目的。
这里也顺便总结一下目录的可读、可写和可执行三个权限的含义。其实目录本身也是文件，其内容是其子层目录结构，比如目录中的文件列表，文件属性等。
可读：表示你可以列出目录中有什么文件；
可写：表示你可以在目录中创建、删除文件；
可执行：表示你可以进入该目录；
关于"Kubernetes中CVE-2019-11244漏洞怎么修复"这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。
