カーネルのどの部分がネームスペースをサポートしていませんか？ [閉鎖]

脆弱性ですが、言及したタイプではありません。

任意のDockerコンテナを作成して実行できるユーザーは、ホストファイルシステムのマップされた部分を使用してコンテナを作成できます。その後、コンテナからrootとして実行して、ディスク上にsetuid rootプログラムを作成できます。その後、ホストでこのコマンドを実行してroot権限を取得できます。

これは非常にオープンなので、素晴らしいですが、答えにくい質問です。

「コード」の意味に応じて、「コードをルートネームスペースで実行できる」部分に焦点を当てます。

• 名前空間がなくても、ユーザー空間の部分は分離する必要があります。つまり、作成するすべてのコードは、名前空間に関係なく他のすべてのコードとは別に実行されます。
• システムコールを介して呼び出されると、カーネル自体から常にすべてにアクセスできます（仮想マシン自体ではない限り）。これは、カーネル部分が何らかの方法で分離されないことを意味します。 [1]

上記 #2 の意味は、プロセス別抽象化を通じてネームスペースを認識するということです。つまり、プロセステーブルの対応するエントリは、名前空間の一部（ルートファイルシステムなど）を直接または間接的に指します。その時点から、カーネル側の何かが正しく動作する限り、常に正しいデータセットにアクセスするという点で「分離」する必要があります。

しかし、これはバグが他のコンテナを含む実行中のシステムのすべての側面に影響を与えることができないという意味ではありません。

隔離されたシステムで何かを実行するには、仮想マシン全体またはLinuxユーザースペースが必要です。コンテナは、プロセスとそれらが表示してアクセスできるターゲットを分離するように設計されています。エラーが発生した場合は、通常のプロセスが最終的にルートでコードを実行できるように制限を超える可能性があります。

[1] システムに関連するほとんどすべての作業は、システムコールを使用して実行されます。たとえば、ファイルを開く、ソケットに書き込む、信号を送信するなどです。