最近、Podmanチームは、ルートレスPodmanによるコンテナの実行を停止する方法がないと主張するBugzillaレポートを受け取りました。レポーターは、/etc/subuidにエントリがないユーザーアカウントを設定しました および/etc/subgid そして、rootlessPodmanがまだhello-worldを実行できると報告しました コンテナ。
誤った仮定
/etc/subuidからユーザー情報を削除する ユーザーがPodmanを使用することを妨げることはありません。誰かがルートレスPodmanを使用してコンテナを実行したときに何が起こっているのかを詳しく見てみましょう。
まず、hello-worldのようなコンテナイメージを認識します コンテナイメージレジストリと呼ばれるウェブサーバーにあるJSONコンテンツと一緒の単なるtarballです。 Webサーバーと通信できるアプリケーションはすべて、標準のWebプロトコルやcurlなどのツールを使用してサーバーをプルダウンできます。 。
Podmanが画像をプルダウンすると、最初にユーザー名前空間が作成されて入力されます。このユーザー名前空間は通常、ユーザーのUIDをユーザー名前空間内のroot（UID =0）にマップします。次に、/etc/subuidを調べます。 ユーザーの場合、そこにリストされているUIDを使用して、ユーザー名前空間内で使用可能な残りのUIDを入力します。 /etc/subgidを介したグループでも同じことを行います 。 /etc/subuidにエントリがない場合 および/etc/subgid の場合、ユーザー名前空間は、rootとしてマップされたユーザーのUIDのみで構成されます。ユーザーの名前空間が設定されると、Podmanは画像のtarコンテンツを抽出します。画像にUID=0以外のユーザーが所有するファイルがある場合、Podmanは抽出してchownを試みます。 定義されたユーザーとグループへのコンテンツ。ユーザーとグループがユーザー名前空間内で定義されていない場合は、chown 失敗し、Podmanは失敗します。
Bugzillaの例では、レポーターがhello-worldを実行しようとしました 。
$ podman run hello-world
Resolved "hello-world" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull docker.io/library/hello-world:latest...
Getting image source signatures
Copying blob b8dfde127a29 done
Copying config d1165f2212 done
Writing manifest to image destination
Storing signatures
Hello from Docker!
…
ユーザーが/etc/subuidにエントリを持っていなくても機能しました および/etc/subgid 。
ユーザーの名前空間を入力して、何が起こっているかを見てみましょう。
Podman unshare cat /proc/self/uid_map
0 3267
私のアカウントは/etc/subuidにアクセスせずに設定されていることに注意してください 。 Podmanは、1つのUIDの範囲でUID3267をUID0にマッピングしています。次に、コンテナイメージhello-worldの内容を見てみましょう。 。ユーザーの名前空間を入力し、hello-worldをマウントします 画像を表示し、内容を一覧表示します。
$ podman unshare
# mnt=$(podman image mount hello-world)
# ls -l $mnt
total 16
-rwxrwxr-x. 1 root root 13336 Mar 5 18:25 hello
唯一のコンテンツがhelloであることに注意してください 指図。これは静的にリンクされたGOバイナリであり、ユーザー名前空間内のrootが所有し、ホームディレクトリのUID=3267です。
これが、追加のUIDとGIDがなくてもコマンドが機能した理由です。
複数のUIDを使用してコンテナイメージを実行してみましょう。
$ podman run fedora echo hi
Resolved "fedora" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull registry.fedoraproject.org/fedora:latest...
Getting image source signatures
Copying blob 7679c09af385 done
Copying config 3567369c67 done
Writing manifest to image destination
Storing signatures
Error: Error committing the finished image: error adding layer with blob "sha256:7679c09af3851a1622782c74864351c296a0d1886813862fd7116383aeba9f07": Error processing tar file(exit status 1): potentially insufficient UIDs or GIDs available in user namespace (requested 0:12 for /var/spool/mail): Check /etc/subuid and /etc/subgid: lchown /var/spool/mail: invalid argument
Podmanがtarballをプルダウンできることに注意してください（これは、tarballをブロブと呼びます）。それらを抽出しようとすると、chownしようとすると失敗します。 /var/spool/mail ユーザー名前空間内で定義されていないGID（12）へのディレクトリであり、コンテナは失敗します。
結論
特権のないコンテナを実行することは安全であり、システムにログインするだけでシステムに実際に影響を与えることはできません。 Podmanユーザーは、通常のユーザーが実行できるタスクを実行します。Webサーバーからコンテンツをプルし、それらを解凍します。最後に、ユーザーはコンテンツを実行することもできます。唯一の失敗は、ユーザーがchownなどのコマンドを介して許可されていないUIDに切り替えようとしたときに発生します。 またはsu 。
上記の例では、Podmanは追加の特権を必要とすることは何もしませんでした。ユーザーがPodmanを介して実行したすべてのプロセスは、他のユーザープロセスと同じ制約下にありました。実際には、SELinux、SECCOMP、およびその他のセキュリティメカニズムでラップされているため、より制約があります。
ルートレスPodmanを使用してコンテナイメージを実行することは、ユーザーがWebサーバーから実行可能ファイルをダウンロードしてホームディレクトリで実行できるようにすることと同じくらい安全です。
それでもシステム上の特定のユーザーがPodmanを実行できないようにする場合は、Podman自体の権限を変更する必要があります。
# chmod 750 /usr/bin/podman
# groupadd podman
# chown root:podman /usr/bin/podman
Podmanへのアクセスを許可するユーザーをpodmanグループに追加します。 Podmanが更新されたら、chmodを実行する必要があることを理解してください。 およびchown もう一度コマンドを実行し、rpm -qV podman インストールに関する問題を報告します。
追加クレジット
上級ユーザー、特にハイパフォーマンスコンピューティング（HPC）のユーザー向けに、特別なフラグignore_chown_errorsを追加しました。 、コンテナのストレージに。
man storage.conf
…
ignore_chown_errors = "false"
ignore_chown_errors can be set to allow a non privileged user running with a single UID within a user namespace to run containers. The user can pull and use any image, even those with multiple uids. Note multiple UIDs will be squashed down to the default uid in the container. These images will have no separation between the users in the container. (default: false)
/etc/containers/storage.confでこのフラグを設定する $HOME/.config/containers/storage.confの 本当のところ、PodmanはFedoraコンテナーを正常に実行できます。
$ grep ignore_chown_err /etc/containers/storage.conf
# ignore_chown_errors can be set to allow a non privileged user running with
ignore_chown_errors = "true"
$ podman unshare cat /proc/self/uid_map
0 3267 1
$ podman run fedora echo hi
Resolved "fedora" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull registry.fedoraproject.org/fedora:latest...
Getting image source signatures
Copying blob 7679c09af385 done
Copying config 3567369c67 done
Writing manifest to image destination
Storing signatures
hi
今回、Podmanがchownを試みたとき /var/spool/mail ディレクトリとエラーを受け取り、それを無視して続行しました。 HPCは、ユーザーが複数のUIDを持つことを望まないため、ユーザーは標準のOCIイメージを実行できますが、セキュリティ設定をまったく緩める必要はありません。コンテナ内で実行するUIDがコンテナのルートのみである限り、これは正常に機能することに注意してください。何らかの理由で、プロセスがUIDをコンテナ内で定義されていないUIDに変更しようとすると、失敗します。また、ほとんどの場合、画像内のすべてのファイルはユーザーが所有します。コンテナのそのユーザーは、すべてのコンテンツに対する完全な読み取り/書き込み権限を持っています。
[コンテナを使い始めますか？この無料コースをチェックしてください。コンテナ化されたアプリケーションのデプロイ：技術的な概要。 ]
まとめ
Podman管理者は、許可されているアクセスレベルを認識している必要があります。 /etc/subuidの意図と機能を確実に理解してください および/etc/subgid 、およびそれらがコンテナのセキュリティにどのように影響するか。
最後に、ignore_chown_errorsを使用します 慎重にオプション。 HPCシナリオ向けに設計されました。