我們團隊開發的產品基於Kubernetes，雖然Kubernetes已經非常安全，但我們產品有更高的安全要求，所以常常需要對Kubernetes做安全加固。

最近在審視安全加固程式碼時，發現有個安全漏洞（CVE-2019-11244）好像已被Kubernetes社群（後面簡稱社群）“修復”了，這裡修復加了引號表示我個人並不完全認可修復方案，可能社群並沒有徹底修復該漏洞，只是把問題減輕了。

本文我們深度分析一下這個漏洞，並探討一下這個漏洞應該如何修復。

背景知識

為了能更好的理解這個漏洞，需要一些關於Linux 檔案許可權的基礎知識。

也許你經常使用chmod命令來為某個檔案設定許可權，比如給某個檔案設定許可權：chmod 755 xxx

在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，這些快取檔案有被其他使用者修改的風險。

這裡其他使用者是包含兩類：

1. 同group下的其他使用者（後面稱group使用者）；
2. 不同group的其他使用者（後面稱other使用者）；

那麼修復這個漏洞，就要收縮這些檔案許可權，只要做到這些檔案不能被這兩類使用者修改即可（可以擁有讀許可權）。

社群修復方案

kubelet會建立一個專門的目錄來存放級存檔案，所以這裡既要控制目錄許可權還要控制檔案的許可權。

在社群的修復方案中，目錄許可權由755變成了750，即other使用者將不能