建站
咨詢
售后
建站咨詢
新聞中心
Podman（Pod Manager）是一個功能齊全的容器引擎，它是一個簡單的無守護工具。 Podman提供了一個類似Docker-CLI的命令行，可以簡化從其他容器引擎的轉換，并允許管理pod，容器和圖像。
創(chuàng)新互聯是一家專注于成都網站設計、成都做網站與策劃設計,潛江網站建設哪家好?創(chuàng)新互聯做網站,專注于網站建設10余年,網設計領域的專業(yè)建站公司;建站業(yè)務涵蓋:潛江等地區(qū)。潛江做網站價格咨詢:028-86922220
什么是審計？
Linux 內核有一個有趣的安全功能，叫做審計。它允許管理員在系統(tǒng)上監(jiān)視安全事件，并將它們記錄到audit.log 中，該文件可以本地存儲或遠程存儲在另一臺機器上，以防止黑客試圖掩蓋他的蹤跡。
/etc/shadow 文件是一個經常要監(jiān)控的安全文件，因為向其添加記錄可能允許攻擊者獲得對系統(tǒng)的訪問權限。管理員想知道是否有任何進程修改了該文件，你可以通過執(zhí)行以下命令來執(zhí)行此操作：
# auditctl -w /etc/shadow
現在讓我們看看當我修改了/etc/shadow 文件會發(fā)生什么：
# 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 中，它是系統(tǒng)上每個進程的 proc 結構的一部分。該字段只能設置一次；設置后，內核將不允許任何進程重置它。
當我登錄系統(tǒng)時，登錄程序會為我的登錄過程設置 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運行容器更安全？為什么Podman運行容器更安全？
Podman 對于容器使用傳統(tǒng)的 fork/exec 模型，因此容器進程是 Podman 進程的后代。Docker 使用客戶端/服務器模型。我執(zhí)行的 docker 命令是 Docker 客戶端工具，它通過客戶端/服務器操作與 Docker 守護進程通信。然后 Docker 守護程序創(chuàng)建容器并處理 stdin/stdout 與 Docker 客戶端工具的通信。
進程的默認 loginuid（在設置 loginuid 之前）是 4294967295（LCTT 譯注：232 – 1）。由于容器是 Docker 守護程序的后代，而 Docker 守護程序是 init 系統(tǒng)的子代，所以，我們看到 systemd、Docker 守護程序和容器進程全部具有相同的 loginuid：4294967295，審計系統(tǒng)視其為未設置審計 UID。
cat /proc/1/loginuid
4294967295
為什么不一樣？
讓我們來看看如果 Docker 啟動的容器進程修改/etc/shadow 文件會發(fā)生什么。
$ 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 容器，那么在系統(tǒng)上誰修改 /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)
由于它使用傳統(tǒng)的 fork/exec 方式，因此 Podman 正確記錄了所有內容。
這只是觀察 /etc/shadow 文件的一個簡單示例，但審計系統(tǒng)對于觀察系統(tǒng)上的進程非常有用。使用 fork/exec 容器運行時（而不是客戶端/服務器容器運行時）來啟動容器允許你通過審計日志記錄保持更好的安全性。
最后的想法
在啟動容器時，與客戶端/服務器模型相比，fork/exec 模型還有許多其他不錯的功能。例如，systemd 功能包括：
SD_NOTIFY：如果將 Podman 命令放入 systemd 單元文件中，容器進程可以通過 Podman 返回通知，表明服務已準備好接收任務。這是在客戶端/服務器模式下無法完成的事情。 套接字激活：你可以將連接的套接字從 systemd 傳遞到 Podman，并傳遞到容器進程以便使用它們。這在客戶端/服務器模型中是不可能的。
在我看來，其最好的功能是作為非 root 用戶運行 Podman 和容器。這意味著你永遠不會在宿主機上授予用戶 root 權限，而在客戶端/服務器模型中（如 Docker 使用的），你必須打開以 root 身份運行的特權守護程序的套接字來啟動容器。在那里，你將受到守護程序中實現的安全機制與宿主機操作系統(tǒng)中實現的安全機制的支配 —— 這是一個危險的主張。
分享名稱：Podman的安全體現在哪些方面
當前網址：http://fisionsoft.com.cn/article/cdccjjd.html
