Skip to content

容器基礎映像檔要選 Debian 還是 Ubuntu?

來問問大家一個問題，以 Container Base Images 來說，以 Deb 體系來看，你覺得 Debian 比較安全還是 Ubuntu 比較安全?

容器映像檔的靜態掃描 (Static Analysis) 方式

以現行資安服務掃 Container Images，絕大部分都是以靜態掃描為主 (動態跑沙箱內的請容我先跳過)，掃的方式主要都是看裡面的安裝中套件有沒有使用到有漏洞的套件 (可用 apt list --installed 條列安裝中的套件和版本) 然後對上已知的 CVE Database，以 Harbor 提供的 Harbor Compatibility List- Scanner Adapters，無論是 clair / sysdig / aqua / trivy 實作招數都是差不多的

$ date
Thu Jun 29 23:25:30 CST 2023

$ docker run -it --rm --name debug docker.io/library/ubuntu:22.04 /bin/bash
root@82f6bb20f606:/# apt list --installed | head -n 10

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

Listing...
adduser/now 3.118ubuntu5 all [installed,local]
apt/now 2.4.9 amd64 [installed,local]
base-files/now 12ubuntu4.3 amd64 [installed,local]
base-passwd/now 3.5.52build1 amd64 [installed,local]
bash/now 5.1-6ubuntu1 amd64 [installed,local]
bsdutils/now 1:2.37.2-4ubuntu3 amd64 [installed,local]
coreutils/now 8.32-4.1ubuntu1 amd64 [installed,local]
dash/now 0.5.11+git20210903+057cd650a4ed-3build1 amd64 [installed,local]
debconf/now 1.5.79ubuntu1 all [installed,local]

root@82f6bb20f606:/# cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.2 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.2 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy

以作業系統角度條列已知 CVE

可以觀察兩邊的 Security Tracker．選 High 就好

  1. Debian - Security Bug Tracker 他所有版號都會列出來，buster (10,oldoldstable,LTS) / bullseye (11,oldstable) / bookworm (stable) 三個版本都可以看一下
  2. Ubuntu- CVE search results 以 22.04 LTS 為主

建議可以看常上 CVE 列表的 linux* 開頭的套件，你會發現到幾個事實

  1. 無論是 Ubuntu 或 Debian，不是每一個 CVE 標註 High 在上游套件都有被修復，所以你就算 apt update && apt upgrade 更新到最新版，不一定能會關掉所有 CVE High 的問題

  2. CVE 會隨你的作業系統 OS 和發布版號 cat /etc/os-release 有下列 4 個不同的呈現結果

    1. 舊版沒有這個問題，但新版發行版有，譬如 CVE-2023-35829
    2. 舊版不修，但新版修了，譬如 CVE-2023-23005
    3. 剛發現還不知道怎麼修，譬如 CVE-2023-35827
    4. 看起來是沒人想修，譬如 CVE-2020-36694

總歸來說，如果你更新到最新的版本，無論是 Debian 還是 Ubuntu 你都還是會有幾個 CVE High 的問題會亮在你的報告上，那怎麼辦? 嚴格來說你也只能等社群某個人幫忙做套件更新，或者是用其他非技術的方式解決，畢竟不是每個 CVE 都能被利用或好利用

既然都沒辦法完全修到沒有，那要怎麼選擇?

以現在 2023 這個時間點來說，不如平心而論，主要可以對比兩邊 CVE 的處理反應速度和能不能做 backport (向後移植)

  • Debian Security FAQ: 基本上比較偏社群自主運作，你得回報到，或自己捲起手修復，而且有問題修復的時候，按照 Q: 套件的版本號表明我仍在運行受漏洞影響的版本！ 的說法是 A: 我們將安全補丁向後移植到穩定發行版 (Stable Release) 中隨附的套件版本，而不是升級到新版本
  • Ubuntu - Long Term Supported OCI Images: 這個因為有 Canonical 後面投人力下去維護，按照 Is the LTS Docker Image Portfolio a free or a commercial offering? 的說法，所以最小 5y LTS 更新，有訂閱買支援的話最長 10y 的安全修補，其實跟 Red Hat / SUSE 銷售模式是大同小異，這種比較有人力做 backport，意思是說現在的 patch 可以回朔到前面的版本去修復

故就商用支援來說，Canonical 因為有既有的商業模式支撐他們養工程師，故整體採用風險來說，還相對比 Debian 低一點，更何況 Ubuntu 真的是太多公司 (e.g. Cloud Provider / OEM) 預設有用，無論是有沒有走 Partner Channel 訂閱，或者是 OEM 路線

結論

結論來說，如果叫我選擇 Debian 體系的 Container Base Images ，下列提供個人主觀判斷...

準則如下，從商務解到技術解:

  1. 重視 Security 修復能量
  2. 跟著底層作業系統 (Host OS) 選: 因為 Container 是共用 Host OS Kernel，如果剛好你用到的功能有這種偏特定 Kernel 的 lib 或套件，那建議跟著 Host OS 選，如果沒這種需求，還是建議跟著 Host OS 選，其次才選別的
  3. 拉最新版本: dockerfile 開頭記得要先 apt update && apt upgrade
  4. 走 Distroless: 裝最少但必須的套件，不要裝多餘套件，但這個需要對 Multi Stage Build 有高度理解的工程團隊才可以選的技術解法

順序如下:

  1. docker.io/library/ubuntu:22.04
  2. Distroless 體系
  3. docker.io/library/debian:bookworm

Q&A

Q1: 可是人家說不是 Debian 比較穩定? Ubuntu 比較不穩定?

具體來說，可以先試問自己，何謂穩定的定義? 不常更新的發行版、少人使用的發行版、少漏洞的發行版? 這些都有聽過，但這個跟商務使用上的關係要怎麼掛勾起來，可以用實務面問題來討論，CVE 套件報告就亮在那邊，請問要找誰處理修復?

關鍵重點是誰 (Who) 去修，反而不是 CVE Database，因為 CVE 你擋了一個明天還會有下一個，基本上沒什麼特別可以討論，看看今年 2023 才過一半 CVE 編號已經來到 14141，但誰 (Who) 要提供處理方式是一個很重要的事情，無論是修補 (Fixed) 或者是緩解 (Mitigation)

Q2: 不是按 apt update && apt upgrade 就可以修補全部 CVE 的東西嗎?

細分來講，套件庫還有分 Ubuntu / Debian 官方收編正式支援的套件庫，和第三方套件庫 (e.g. PPA 或其他掛 apt-repos / dpkg -i) 的安裝，千萬不要期望全部套件都能一發解決的，所以有可能你 CVE 亮半天，有高度機會等到他生命周期結束還是會繼續亮著

Q3: 我就是不想付錢，但我又要有較高的安全性，怎麼辦?

最佳做法就是 "請持續保持最新版本"，因為現行多數發行版，鮮少會持續 backport 回去到舊有的版本，你如果是思考完全不更新，不代表就是安全，然後就沒你的事了，你只是選擇把技術債留到之後再來處理，中間的時間就是風險所在，需要自行評估

以一個線性開發的模式來看，你想想你以前寫的 code 出問題了，在不具備任何 SLA 商務保證下，你是會修在最新的版本，還是要花大量時間往回修? 維護是需要人力成本的

Q4: 社群不是都會自動提供修補方式嗎?

社群，是由一堆志願者花時間貢獻或者是有受雇特定公司做限定範圍的事情，漏洞會被修補是因為有別的維護者或公司剛好有這個需求貢獻出來，絕對不是無中生有的

但以前或許你不用想這些套件怎麼來的，畢竟用的人不是大宗，但隨著數位發展的普及性，Linux 和 OpenSource 的採用跟陽光空氣水一樣的自然，進而發生蠻多起開源軟體供應鏈攻擊 (Software Supply Chain Attacks)，各個都是地圖炮等級，看看之前的 NPM、PyPI 的攻擊範圍，還有那個基本上人人都有用到但極少人在乎他到底怎麼誕生的 OpenSSL。嚴重到 2021/5/21 美國總統都簽署行政命令 Executive Order 14028, “Improving the Nation’s Cybersecurity 進行 SBOM 和 Software Supply Chain 的規範

Q5: 如果用 Ubuntu / Debian 的 Base Images 或相關套件招致攻擊，這個算誰的責任?

使用者責任，風險需自負

Q6: 我不想要出事的時候自己擔政治責任，那怎麼辦?

風險轉嫁 (a.k.a 找背鍋俠)

  1. 治本的方式就是找有 SLA 的公司負責，例如 Canonical / Red Hat / SUSE 等等，這些公司都有提供商業支援，但這些都是要付費的，不是免費的
  2. 治標的方式就是資安設備用架構面築起強化防護的能力，但還是要花錢

不花錢的風險轉嫁...如果知道的人，請留言或私訊教我一下

Q7: 上述論述適用於單純只是要選擇作業系統上嗎?

是，本文論述不僅限定於在 Base Images 的選擇﹐也可包含單純 Deb 體系的作業系統選擇說明

Q8: 敏感一點的問題，Ubuntu / Red Hat / SUSE?

我個人支持投注很多精力在 貢獻 Upstream Open Source Project 的公司上，這才是我認知比較正常的開源生態系，所以要我排的話就是 Red Hat == SUSE > Ubuntu，但這只是我個人的看法，畢竟比較以前常撞到前兩家的人

Q9: 為啥這世界跟以前好像不太一樣?

聽首陳奕迅的歌十年回味一下，我大概是十年多以前接觸 Linux，用最久的版本是 Ubuntu 10.04，老實說當時真心沒這麼複雜，但現在因為採用的人多，整個生態系相當蓬勃，做法也會相對多樣化，所以才會有一票開源專案的治理模式 (Governance)