Podman:一個更安全的執行容器的方式
Podman 使用傳統的 fork/exec 模型(相對於客戶端/伺服器模型)來執行容器。
在進入本文的主要主題 Podman 和容器之前,我需要了解一點 Linux 審計功能的技術。
什麼是審計?
Linux 核心有一個有趣的安全功能,叫做審計。它允許管理員在系統上監視安全事件,並將它們記錄到audit.log
中,該檔案可以本地儲存或遠端儲存在另一臺機器上,以防止黑客試圖掩蓋他的蹤跡。
/etc/shadow
檔案是一個經常要監控的安全檔案,因為向其新增記錄可能允許攻擊者獲得對系統的訪問許可權。管理員想知道是否有任何程式修改了該檔案,你可以通過執行以下命令來執行此操作:
# auditctl -w /etc/shadow
現在讓我們看看當我修改了 /etc/shadow
檔案會發生什麼:
# touch /etc/shadow
# ausearch -f /etc/shadow -i -ts recent
type=PROCTITLE msg=audit(10/10/2018 09:46:03.042:4108) : proctitle=touch /etc/shadow type=SYSCALL msg=audit(10/10/2018 09:46:03.042:4108) : arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffff9c a1=0x7ffdb17f6704 a2=O_WRONLY|O_CREAT|O_NOCTTY| O_NONBLOCK a3=0x1b6 items=2 ppid=2712 pid=3727 auid=dwalsh uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=3 comm=touch exe=/usr/bin/touch subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)`
審計記錄中有很多資訊,但我重點注意到它記錄了 root 修改了 /etc/shadow
檔案,並且該程式的審計 UID(auid
)的所有者是 dwalsh
。
核心修改了這個檔案了麼?
跟蹤登入 UID
登入 UID(loginuid
),儲存在 /proc/self/loginuid
中,它是系統上每個程式的 proc 結構的一部分。該欄位只能設定一次;設定後,核心將不允許任何程式重置它。
當我登入系統時,登入程式會為我的登入過程設定 loginuid
欄位。
我(dwalsh
)的 UID 是 3267。
$ cat /proc/self/loginuid
3267
現在,即使我變成了 root,我的登入 UID 仍將保持不變。
$ sudo cat /proc/self/loginuid
3267
請注意,從初始登入過程 fork 並 exec 的每個程式都會自動繼承 loginuid
。這就是核心知道登入的人是 dwalsh
的方式。
容器
現在讓我們來看看容器。
sudo podman run fedora cat /proc/self/loginuid
3267
甚至容器程式也保留了我的 loginuid
。 現在讓我們用 Docker 試試。
sudo docker run fedora cat /proc/self/loginuid
4294967295
為什麼不一樣?
Podman 對於容器使用傳統的 fork/exec 模型,因此容器程式是 Podman 程式的後代。Docker 使用客戶端/伺服器模型。我執行的 docker
命令是 Docker 客戶端工具,它通過客戶端/伺服器操作與 Docker 守護程式通訊。然後 Docker 守護程式建立容器並處理 stdin/stdout 與 Docker 客戶端工具的通訊。
程式的預設 loginuid
(在設定 loginuid
之前)是 4294967295
(LCTT 譯註:232 - 1)。由於容器是 Docker 守護程式的後代,而 Docker 守護程式是 init 系統的子代,所以,我們看到 systemd、Docker 守護程式和容器程式全部具有相同的 loginuid
:4294967295
,審計系統視其為未設定審計 UID。
cat /proc/1/loginuid
4294967295
怎麼會被濫用?
讓我們來看看如果 Docker 啟動的容器程式修改 /etc/shadow
檔案會發生什麼。
$ sudo docker run --privileged -v /:/host fedora touch /host/etc/shadow
$ sudo ausearch -f /etc/shadow -i type=PROCTITLE msg=audit(10/10/2018 10:27:20.055:4569) : proctitle=/usr/bin/coreutils --coreutils-prog-shebang=touch /usr/bin/touch /host/etc/shadow type=SYSCALL msg=audit(10/10/2018 10:27:20.055:4569) : arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffff9c a1=0x7ffdb6973f50 a2=O_WRONLY|O_CREAT|O_NOCTTY| O_NONBLOCK a3=0x1b6 items=2 ppid=11863 pid=11882 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=touch exe=/usr/bin/coreutils subj=system_u:system_r:spc_t:s0 key=(null)
在 Docker 情形中,auid
是未設定的(4294967295
);這意味著安全人員可能知道有程式修改了 /etc/shadow
檔案但身份丟失了。
如果該攻擊者隨後刪除了 Docker 容器,那麼在系統上誰修改 /etc/shadow
檔案將沒有任何跟蹤資訊。
現在讓我們看看相同的場景在 Podman 下的情況。
$ sudo podman run --privileged -v /:/host fedora touch /host/etc/shadow
$ sudo ausearch -f /etc/shadow -i type=PROCTITLE msg=audit(10/10/2018 10:23:41.659:4530) : proctitle=/usr/bin/coreutils --coreutils-prog-shebang=touch /usr/bin/touch /host/etc/shadow type=SYSCALL msg=audit(10/10/2018 10:23:41.659:4530) : arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffff9c a1=0x7fffdffd0f34 a2=O_WRONLY|O_CREAT|O_NOCTTY| O_NONBLOCK a3=0x1b6 items=2 ppid=11671 pid=11683 auid=dwalsh uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=3 comm=touch exe=/usr/bin/coreutils subj=unconfined_u:system_r:spc_t:s0 key=(null)
由於它使用傳統的 fork/exec 方式,因此 Podman 正確記錄了所有內容。
這只是觀察 /etc/shadow
檔案的一個簡單示例,但審計系統對於觀察系統上的程式非常有用。使用 fork/exec 容器執行時(而不是客戶端/伺服器容器執行時)來啟動容器允許你通過審計日誌記錄保持更好的安全性。
最後的想法
在啟動容器時,與客戶端/伺服器模型相比,fork/exec 模型還有許多其他不錯的功能。例如,systemd 功能包括:
SD_NOTIFY
:如果將 Podman 命令放入 systemd 單元檔案中,容器程式可以通過 Podman 返回通知,表明服務已準備好接收任務。這是在客戶端/伺服器模式下無法完成的事情。- 套接字啟用:你可以將連線的套接字從 systemd 傳遞到 Podman,並傳遞到容器程式以便使用它們。這在客戶端/伺服器模型中是不可能的。
在我看來,其最好的功能是作為非 root 使用者執行 Podman 和容器。這意味著你永遠不會在宿主機上授予使用者 root 許可權,而在客戶端/伺服器模型中(如 Docker 使用的),你必須開啟以 root 身份執行的特權守護程式的套接字來啟動容器。在那裡,你將受到守護程式中實現的安全機制與宿主機作業系統中實現的安全機制的支配 —— 這是一個危險的主張。
via: https://opensource.com/article/18/10/podman-more-secure-way-run-containers
作者:Daniel J Walsh 選題:lujun9972 譯者:wxy 校對:wxy
訂閱“Linux 中國”官方小程式來檢視
相關文章
- 為什麼Podman執行容器更安全?
- 以沙箱的方式執行容器:安全容器gvisor
- 以沙箱的方式執行容器:安全容器Kata ContainersAI
- 無需sudo使用Podman在Linux上執行容器Linux
- Podman中如何執行一個 Linux 虛擬機器?Linux虛擬機
- 進入正在執行的Docker容器的4種方式Docker
- RHCE(podman容器)
- 容器不是執行緒安全執行緒
- Docker 與 Podman 容器管理的比較Docker
- podman安裝和普通使用者使用podman的方式及podman常用命令
- Map實現執行緒安全的3種方式執行緒
- 通過執行一個tomcat容器來記錄下初學docker常用的幾個命令---容器篇TomcatDocker
- 【Flask】第一個Flask程式(安裝、執行引數、執行方式)Flask
- 用 Podman Compose 管理容器
- 為什麼建議一個容器中只執行一個程式
- 讓字串執行的方式字串
- Docker入門系列之一:在一個Docker容器裡執行指定的web應用DockerWeb
- 怎樣停止一個正在執行的執行緒執行緒
- 004、執行第一個容器(2018-12-19 週三)
- Java中確保執行緒安全最常用的兩種方式Java執行緒
- Java之執行緒安全問題的3種處理方式(通過執行緒同步)Java執行緒
- jdk建立執行緒的方式JDK執行緒
- Java執行緒(一):執行緒安全與不安全Java執行緒
- docker(podman)容器設定中文環境Docker
- Java多執行緒之—Synchronized方式和CAS方式實現執行緒安全效能對比Java執行緒synchronized
- 容器進階:執行環境的一致性
- Docker命令-docker exec-在執行的容器中執行命令Docker
- 在Linux上以容器方式執行安卓系統的開源專案:WaydroidLinux安卓
- 聊聊保證執行緒安全的10個小技巧執行緒
- 【Java多執行緒】執行緒安全的集合Java執行緒
- 通過執行一個tomcat容器來記錄下初學docker常用的幾個命令---映象篇TomcatDocker
- 建立執行緒的三種方式執行緒
- 【Java】執行緒的建立方式Java執行緒
- 執行緒建立的四種方式執行緒
- 我們該如何正確的中斷一個執行緒的執行??執行緒
- 不使用synchronized和lock,如何實現一個執行緒安全的單例?synchronized執行緒單例
- 【設計模式】實現執行緒安全單例模式的五種方式設計模式執行緒單例
- 通過命令驗證docker容器相當一個輕量級的Linux執行環境,且每個容器內都有一個屬於自己的檔案系統,容器之間相互隔離DockerLinux