☰

LXC：rootユーザーとエンドユーザーが所有する権限のないコンテナーの間にセキュリティ上の違いはありますか？

tag-icon • tag-icon linux security lxc namespace
LXC：rootユーザーとエンドユーザーが所有する権限のないコンテナーの間にセキュリティ上の違いはありますか？

私はLXCコンテナを使用してほとんどのネットワーク接続サービスを分離する予定です。

私が理解したのは、これを行う2つの主な方法です。

  1. ルート所有の権限のないコンテナの作成。この場合、ルートには大規模な子UIDと子GIDセットがあり、その範囲の他のサブセットは各コンテナの影響を受けます（どのコンテナも子UIDまたは子GIDを共有しません）。 、

  2. 権限のないシステムアカウントが所有する権限のないコンテナの作成。この場合、各アカウントにはコンテナとそのコンテナに必要な依存UIDとGIDがあります。

ユーザビリティの観点から見ると、電子ははるかに優れています。セットアップとメンテナンスが簡単です。

しかし、セキュリティの観点から、両者に違いはありますか？

たとえば、

  • に定義されている同じプール（同じ行）に属するIDと他のユーザー、つまり別のプール（別の行）に属するIDを比較すると、リンクまたは/etc/subuid水平関係はありますか？/etc/subgid

  • 子IDと所有者アカウントの間にリンクまたは垂直関係がありますか？ルートが所有する子IDは、権限のないユーザーが所有する子IDよりも高い権限を持つことができますか？他のランダムIDよりも簡単にサブIDを所有者IDにアップグレードできますか？

  • ルートが所有するということは、コンテナを管理するすべてのコマンドがホスト上でroot権限で実行されることを意味します。これは弱点を構成していますか、それともすべての特権が早期に放棄されますか？

  • など。

つまり、ルートが所有する権限を持たないコンテナは、標準アカウントが所有するコンテナよりも「権限が少ない」ことが可能ですか？

答え1

つまり、ルートが所有する権限を持たないコンテナは、標準アカウントが所有するコンテナよりも「権限が少ない」ことが可能ですか？

私はそうは思わない。重要なことは、/proc/$PID/uid_mapコンテナのユーザー名前空間にあるプロセスではなく、次の/etc/subuidコマンドを実行すると想定しています。初期ユーザーの名前空間（つまり、コンテナではない）$PIDコンテナで実行されているプロセスでは：

$ cat /proc/$PID/uid_map
0 200000 1000

これは、$ PIDプロセスのUID範囲が対応する（コンテナ）ユーザー名前空間の外側のUID範囲[0-1000)にマップされることを意味します。[200000-201000)範囲外のUIDはコンテナの65534（）[200000-201000)にマップされます。$(cat /proc/sys/kernel/overflowuid)たとえば、新しいPID名前空間を作成しないと、これが発生する可能性があります。この場合、コンテナ内のプロセスは外部プロセスを見ることができますが、そのUIDは65534です。

したがって、正しいUIDマッピングを使用すると、コンテナがルートとして起動されても、そのプロセスは外部に無許可のUIDを持つことになります。

内部依存 UID は/etc/subuid何らかの方法で外部単一 UID に接続されません。このファイルの目的は、権限のないユーザーが複数のUIDを使用してコンテナを起動できるようにすることです（ほとんどのLinuxオペレーティングシステムの場合と同様）。デフォルトでは、権限のないユーザーの場合は、UIDのみをマッピングできます。つまり、UIDが1000で$PIDコンテナのプロセスを参照している場合は、次の操作のみを実行できます。

echo "$N 1000 1" >/proc/$PID/uid_map

$N権限のないユーザーの場合。他のすべては許可されません。より多くの範囲を描くことができれば、つまり

echo "$N 1000 50" >/proc/$PID/uid_map

[1000-1050)コンテナを介してコンテナ外のUIDにアクセスできます。もちろん、外部UID範囲の開始を変更できる場合は、root権限を簡単に取得できます。したがって、/etc/subuid使用できる外部範囲を定義します。このファイルはnewuidmapsetuid ルートで使用されます。

$ cat /etc/subuid
woky:200000:50
$ echo '0 200000 50' >/proc/$PID/uid_map
-bash: echo: write error: Operation not permitted
$ newuidmap $PID 0 200000 50
$ # success

詳細ははるかに複雑で、説明するには私が適切な人ではないかもしれませんが、答えをしない方が良いと思います。 :-) マニュアルページuser_namespaces(7)とnewuidmap(1)私が直接研究した内容を確認したい場合もあります。新しいLinuxユーザーネームスペースの最初のプロセスはsetuid（）を呼び出す必要がありますか？。残念ながら、LXCがこのファイルをどのように使用しているのかわかりません。

関連情報