rootful・rootless・privilegedコンテナの違い/rootful_rootless_privileged_container_difference

2024/12/28に開催されたOWASP KansaiのLTの資料です。
https://owasp-kansai.doorkeeper.jp/events/179740

Transcript

1. rootful・rootless・privileged コンテナの違い Kobayashi Shun (@moz_sec)
2. 3 巷で話題のルートレスコンテナ
3. 4 ⼀⽬でわかる違い • ホスト側で作られるプロセスのユーザが異なる rootless コンテナ rootrul コンテナ 作成 コンテナ内 ホストから 作成 コンテナ内 ホストから
4. 5 ⼀⽬でわかる違い • ホスト側で作られるプロセスのユーザが異なる rootless コンテナ rootrul コンテナ rootユーザ(UID: 0) 作成 コンテナ内 ホストから testユーザ(UID: 1000) 作成 コンテナ内 ホストから コンテナから⾒ると同じ
5. 6 以上です
6. 7 • user_namespace(7) による分離の有無 • rootlessコンテナはこれを使うことで、⼀般ユーザでのコンテ ナ作成を実現する 技術的な違い
7. 8 • リソースを隔離する技術 • Linuxカーネルv6.8.0時点では8種類 1. Cgroup: cgroup ルートディレクトリ(v.4.6~) 2. IPC: IPCオブジェクト, POSIXメッセージキュー (v.2.6.19~) 3. Network: ネットワークデバイス・スタック, ポート など(v2.6.26~) 4. Mount: mountポイント (v2.4.19~) 5. PID: プロセスID (v2.6.24~) 6. Time: 時間 (v.5.6~) 7. User: UID, GID(Linux v2.6.19~) 8. UTS: ホスト名, ドメイン名 (v2.6.19~) Namespace rootlessコンテナとroo0ulコンテナの違いはこれ
8. 9 • プロセスがどのNamespaceに属するかは /proc/<PID>/ns/* で確認できる Namespace
9. 10 Namespace • ホストのPID1とコンテナのNamespaceをdiffで⽐較する roo#ulコンテナ rootlessコンテナ cgroup, ipc, mnt, net, pid, uts Namespace が分離されているのは共通 rootlessコンテナではuser Namespaceも 分離されている
10. 11 • user Namespaceを使うことで、実現する • 新しいUser Namespaceを作成してそのNamespaceに⼊ると、そ のuser Namespaceにおいてはrootとなり、コンテナ⽣成に必要 な権限のほとんどを取得できる • user Namespace内のrootと元のroot(実root)は若⼲異なる rootlessコンテナの仕組み
11. 12 • コンテナのUIDとホストのUIDを紐づけることができる • /proc/PID/uid_map に書き込まれる (Namespace内の最初のID) (Namespace外の最初のID) (範囲) • newuidmap(1) が使われる • 同じuser Namespaceのプロセスには継承される • /etc/subuid で各ユーザが指定できるUIDは決められている uid_mapping roo#ulコンテナ rootlessコンテナ コンテナでは UID: 0 ↔ ホスト上では UID: 1000 コンテナのUID: 1~ ↔ホスト上ではUID: 100000~
12. 13 • コンテナランタイムの脆弱性によりコンテナブレイクアウト されても、ホスト側での権限はユーザ権限 • 実際にruncの脆弱性を調べてみると21件 • CVE-2019-5736ではruncバイナリを上書きできるが、rootlessコ ンテナだと上書きできない rootlessコンテナの利点 <>
    $7&
    SVOD TFBSDI
    SFTVMTUT IUUQTDWFNJUSFPSHDHJCJODWFLFZDHJ LFZXPSESVOD <>
    6/*5
    #SFBLJOH
    PVU
    PG
    %PDLFS
    WJB
    SVO$ r &YQMBJOJOH
    $7& IUUQTVOJUQBMPBMUPOFUXPSLTDPNCSFBLJOHEPDLFSWJBSVODFYQMBJOJOHDWF dockerd Container Runtime Linux High Level Low Level gRPC JSON設定ファイル と サブコマンド Container 過去に“Lima+containerd+nerdctlで作るコンテナ環境”で紹介
13. 14 • 複数の⾮rootユーザがコンテナを作成できる rootfulコンテナの場合、root権限を持つか、ユーザをdockerグ ループに追加する必要がある • ⾮rootユーザは⾃⾝が起動したコンテナの /proc/PID/root にア クセスできる /proc/PID/root は mount Namespaceでの / を指す • ネストされたコンテナを分離可能にする rootlessコンテナの利点 rootlessコンテナの場合、⼀般ユーザ rootfulコンテナの場合、rootになるためアクセスできない
14. 15 • ホスト上ではユーザ権限でプロセスが動くため、いくつか制 約はある [5] • ホストの1024番未満のポート番号にバインドできない 例) コンテナは80番ポートで待ち受けできるが、ホストで80番 で待ち受けてポートフォーワードすることは不可 • デフォルト設定では、pingコマンドが使えない • cgroup v2 + systemd のときのみcgroupをサポート • slirp4netnsを使うとネットワークパフォーマンスが低下 rootlessコンテナの制限 <>
    (JU)VC
    DPOUBJOFSTQPENBO SPPUMFTTNE IUUQTHJUIVCDPNDPOUBJOFSTQPENBOCMPCNBJOSPPUMFTTNE
15. 16 • デフォルトでDockerはrootful、Podmanはrootless • ただ、Docker v19.03 以降であれば、以下のコマンドを叩くだ けでrootlessコンテナとして作成できる $ dockerd-rootless-setuptool.sh install • 条件(Ubuntu24.04でデフォルトで満たす) newuidmap(1), newgidmap(1) がインストール済み /etc/subuid, /etc/subgidに65536個以上のUID/GIDが含まれる Dockerでもrootlessコンテナは作れる <>
    %PDLFS
    %PDT
    3PPUMFTT
    NPEF IUUQTEPDTEPDLFSDPNFOHJOFTFDVSJUZSPPUMFTT
16. 17 • 現在rootlessコンテナはサポートされていない • ただ、User Namespacesをサポートする動きはあり、 Kubernetes v1.30でβ機能としてリリース • 近いうちにstableになるかもしれない Kubernetesでは <>
    TQFBDLFS EFDL
    ࣍ͷίϯςφηΩϡϦςΟͷ࣌୅6TFS
    /BNFTQBDF
    8JUI
    B
    1PE IUUQTTQFBLFSEFDLDPNQGODMPVEOBUJWFEBZTVTFSOBNFTQBDFXJUIBQPE 今年のCNDWで紹介されています
17. 21 ここまでが roo#ulコンテナとrootlessコンテナのお話
18. 22 そういえば、dockerのオプションに --privilegedっていうのもあったはず 何が違うの︖
19. 23 • --privileged オプションで作れる • コンテナに対するさまざまな制約を全て削ぎ落とす • LinuxカーネルのcapabiliWesを全て付与 • デフォルトのseccompプロファイルを無効化 • デフォルトのAppArmorプロファイルを無効化 • 全てのデバイスへのアクセスを許可 • /sys/ (=sysfs)を読み書き可能にする • Docker in Dockerを実⾏するなどのユースケースのために存在 特権コンテナ(privilegedコンテナ) <>
    %PDLFS
    EPDT
    QSJWJMFHFE
    DPOUBJOFS IUUQTEPDTEPDLFSDPNSFGFSFODFDMJEPDLFSDPOUBJOFSSVOQSJWJMFHFE
20. 24 • --privileged オプションで作れる • コンテナに対するさまざまな制約を全て削ぎ落とす • LinuxカーネルのcapabiliWesを全て付与 • デフォルトのseccompプロファイルを無効化 • デフォルトのAppArmorプロファイルを無効化 • 全てのデバイスへのアクセスを許可 • /sys/ (=sysfs)を読み書き可能にする • Docker in Dockerを実⾏するなどのユースケースのために存在 特権コンテナ(privilegedコンテナ) <>
    %PDLFS
    EPDT
    QSJWJMFHFE
    DPOUBJOFS IUUQTEPDTEPDLFSDPNSFGFSFODFDMJEPDLFSDPOUBJOFSSVOQSJWJMFHFE
21. 25 capabili3es? seccomp? AppArmor? これら全てLinuxカーネルの機能
22. 26 • プロセスに対して特権を細分化して割り当てる機能 = CAP_SYS_ADMIN: rootユーザが持っている権限 を細分化 • Dockerではデフォルトで割り当てるcapabilityを制限[7] capabilities <>
    %PDLFS
    EPDT
    MJOVYLFSOFMDBQBCJMJUJFT IUUQTEPDTEPDLFSDPNFOHJOFTFDVSJUZMJOVYLFSOFMDBQBCJMJUJFT <>
    (JU)VC
    NPCZPDJDBQTEFGBVMUTHP IUUQTHJUIVCDPNNPCZNPCZCMPCNBTUFSPDJDBQTEFGBVMUTHP 1024番未満のポートを使⽤可能 Rawソケットを使⽤可能 → pingが使える
23. 27 • --cap-addや--cap-dropでできる[9] • --privilegedにしたい時は、ほとんどの場合、--cap-addで capabili;esを付与すれば解決できる • capabili[esはgetpcaps(1)で確認可能 capabilities <>
    %PDLFS
    EPDT
    SVOUJNFQSJWJMFHFBOEMJOVYDBQBCJMJUJFT IUUQTEPDTEPDLFSDPNFOHJOFDPOUBJOFSTSVOSVOUJNFQSJWJMFHFBOEMJOVYDBQBCJMJUJFT 最初に作ったコンテナで確認 p.24で作ったprivilegedコンテナで確認
24. 28 • システムコールを制限する機能 • /boot/configでCONFIG_SECCOMP=yならば有効 Ubuntu 24.04では、デフォルトで有効 • 300以上あるシステムコールの中からDockerではデフォルトで 約44個のシステムコールを無効化[10] seccomp <>
    %PDLFS
    EPDT
    TFDDPNQ IUUQTEPDTEPDLFSDPNFOHJOFTFDVSJUZTFDDPNQQBTTBQSPpMFGPSBDPOUBJOFS
25. 29 seccomp <>
    (JU)VC
    NPCZNPCZ QSPGJMFTTFDDPNQEFGBVMUKTPO IUUQTHJUIVCDPNNPCZNPCZCMPCNBTUFSQSPGJMFTTFDDPNQEFGBVMUKTPO • デフォルトのseccompプロファイルを⼀部抜粋[11] • --security-opt で変更可能 最初に全てのシステムコールを拒否 ホワイトリスト形式で許可していく 権限の条件
26. 30 • 強制アクセス制御(MAC: Mandatory Access Control)を実現 • 所有者がアクセス制御を設定する任意アクセス制御 (DAC: Discretionary Access Control)の逆 • ファイルパスごとに許可・拒否を⾏う コンテナ内でrootであっても、アクセス拒否などができる • aa-status(1)で確認可能 AppArmor <>
    %PDLFS
    EPDT
    QBTTBQSPGJMFGPSBDPOUBJOFS IUUQTEPDTEPDLFSDPNFOHJOFTFDVSJUZTFDDPNQQBTTBQSPGJMFGPSBDPOUBJOFS
27. 31 AppArmor <>
    (JU)VC
    NPCZNPCZ UFNQMBUFHP IUUQTHJUIVCDPNNPCZNPCZCMPCNBTUFSQSPpMFTBQQBSNPSUFNQMBUFHP /proc の拒否 /sys の拒否 • デフォルトのAppArmorプロファイルを⼀部抜粋[12] • --security-opt で変更可能 mount の拒否 runc のシグナル拒否
28. 32 • コンテナに対するさまざまな制約を全て削ぎ落とす • Linuxカーネルのcapabilitiesを全て付与 → ホストのrootと同じ権限 • デフォルトのseccompプロファイルを無効化 → システムコールに制限なし • デフォルトのAppArmorプロファイルを無効化 → 強制アクセス制御が無効 • 全てのデバイスへのアクセスを許可 • /sys/ (=sysfs)を読み書き可能にする 特権コンテナ(privilegedコンテナ) 再掲
29. 33 • Dockerのドキュメントでもできるだけ使わないことを推奨 • コンテナブレイクアウトが容易 Container Security Bookのbreakout-to-hostで紹介されている • 特権コンテナを使う際は、ベストプラクティスに従うこと [12] コンテナ内でrootユーザを使わない ユーザが権限昇格コマンドを実⾏するのを防ぐ(--security-opt no-new-privilegesを使う) 特権コンテナ(privilegedコンテナ) <>
    4OZL
    $POUBJOFS
    JT
    SVOOJOH
    JO
    QSJWJMFHFE
    NPEF IUUQTMFBSOTOZLJPMFTTPODPOUBJOFSSVOTJOQSJWJMFHFENPEF
30. 35 1. 特権コンテナ (--privileged) + コンテナ内でroot 容易にホストにアクセス可 2. 特権コンテナ (--privileged) + コンテナ内で追加したユーザ コンテナ内でrootになると容易にホストにアクセス可 3. rootful + コンテナ内でroot コンテナランタイムの脆弱性が⾒つかるなどするとまずい 4. rootful + コンテナ内で追加したユーザ コンテナ内でrootになったのちに、コンテナブレイクアウト 多層防御(弱い順)
31. 36 5. rootless + コンテナ内でroot コンテナブレイクアウトしたのちに、ホスト上で特権昇格 6. rootless + コンテナ内で追加したユーザ コンテナ内でrootになったのちに、コンテナブレイクアウトし てさらにホスト上で特権昇格 多層防御(弱い順)
32. 37 • むやみに --privileged は使わない 使うなら、最低限コンテナ内でroot以外のユーザを使⽤し、 --security-opt no-new-privileges でrootになるのを防ぐ • デフォルトだとDockerではrootful, Podmanではrootless • コンテナを実現するための技術はなかなか奥が深い • rootlessコンテナの場合、コンテナブレイクアウトできても、 ホスト側ではユーザ権限 • Kubernetesでは、KEP-127: Support User Namespaces に期待 まとめ