Docker 安全非事件
本頁列出了 Docker 已緩解的安全漏洞，因此即使在漏洞修復之前，在 Docker 容器中執行的程序也從未受該漏洞的影響。前提是容器在執行時沒有新增額外的功能，或者沒有以 --privileged 模式執行。
下面的列表遠非完整。相反，它只是我們實際注意到已引起安全審查並公開披露漏洞的少數幾個錯誤的樣本。很可能，未報告的錯誤遠多於已報告的錯誤。幸運的是，由於 Docker 透過 apparmor、seccomp 和放棄功能來實現預設安全的方法，它很可能像緩解已知錯誤一樣有效地緩解未知錯誤。
已緩解的漏洞
- CVE-2013-1956, 1957, 1958, 1959, 1979, CVE-2014-4014, 5206, 5207, 7970, 7975, CVE-2015-2925, 8543, CVE-2016-3134, 3135 等：引入非特權使用者名稱空間導致非特權使用者的攻擊面大幅增加，因為這些使用者可以合法地訪問以前只有 root 使用者才能訪問的系統呼叫，例如
mount()。所有這些 CVE 都是由於引入使用者名稱空間而導致的安全漏洞的例子。Docker 可以使用使用者名稱空間來設定容器，但隨後透過預設的 seccomp 配置檔案禁止容器內的程序建立自己的巢狀名稱空間，從而使這些漏洞無法被利用。 - CVE-2014-0181, CVE-2015-3339：這些是需要存在 setuid 二進位制檔案的漏洞。Docker 透過
NO_NEW_PRIVS程序標誌和其他機制停用了容器內的 setuid 二進位制檔案。 - CVE-2014-4699：
ptrace()中的一個漏洞可能允許許可權提升。Docker 使用 apparmor、seccomp 和放棄CAP_PTRACE的方式在容器內停用ptrace()。這裡有三層保護！ - CVE-2014-9529：一系列精心構造的
keyctl()呼叫可能導致核心 DoS / 記憶體損壞。Docker 使用 seccomp 在容器內停用keyctl()。 - CVE-2015-3214, 4036：這些是常見虛擬化驅動程式中的漏洞，可能允許客戶機作業系統使用者在主機作業系統上執行程式碼。利用它們需要訪問客戶機中的虛擬化裝置。在沒有
--privileged的情況下執行時，Docker 隱藏了對這些裝置的直接訪問。有趣的是，這些情況似乎表明容器比虛擬機器“更安全”，這與虛擬機器比容器“更安全”的普遍看法相悖。 - CVE-2016-0728：由精心構造的
keyctl()呼叫引起的釋放後使用（use-after-free）可能導致許可權提升。Docker 使用預設的 seccomp 配置檔案在容器內停用keyctl()。 - CVE-2016-2383：eBPF（用於表示 seccomp 過濾器等內容的特殊核心 DSL）中的一個漏洞允許任意讀取核心記憶體。在 Docker 容器內部，
bpf()系統呼叫被（諷刺地）使用 seccomp 阻止了。 - CVE-2016-3134, 4997, 4998：setsockopt 與
IPT_SO_SET_REPLACE、ARPT_SO_SET_REPLACE和ARPT_SO_SET_REPLACE存在漏洞，導致記憶體損壞/本地許可權提升。這些引數被CAP_NET_ADMIN阻止，而 Docker 預設不允許此功能。
未緩解的漏洞
- CVE-2015-3290, 5157：核心的非遮蔽中斷處理中的漏洞允許許可權提升。可以在 Docker 容器中利用，因為
modify_ldt()系統呼叫目前沒有被 seccomp 阻止。 - CVE-2016-5195：在 Linux 核心記憶體子系統處理私有隻讀記憶體對映的寫時複製（COW）中斷時發現了一個競爭條件，該條件允許非特權本地使用者獲得對只讀記憶體的寫訪問許可權。也稱為“髒牛”（dirty COW）。部分緩解措施：在某些作業系統上，透過 seccomp 過濾
ptrace以及/proc/self/mem是隻讀的這一事實組合，可以緩解此漏洞。