このコマンドを使用してunshare名前空間を作成するときにホストのルートではなく、ユーザータイプ以外の名前空間を作成すると、次のエラーが発生します。Operation not permitted.明らかにrootとして実行すると動作します。
したがって、 （unshare -n共有解除ネットワーク名前空間）でこのエラーが発生した場合unshare -Un（共有解除ユーザーとネットワーク名前空間）でこのエラーが発生しないのはなぜですか？
私が見たが正しいかどうかわからない最初のオプションは、すべての名前空間が実際にユーザーの名前空間に関連付けられていることです。十分な権限がないと、新しい名前空間を接続できません。ただし、ユーザーの名前空間を作成すると、それを可能にする権限があります。
上記が真であれば、明示的にユーザーとして作成しなくても、すべてのプロセスにユーザーの名前空間があると言えますか？これは他の名前空間にも適用されますか？
編集：コメントで指摘したように、unshare -Un同じエラーが発生する可能性がありますoperation not permitted。ユーザーネームスペースが有効なUbuntu 20.04を使用してテストしました。私はそれが違いだと信じています。
ベストアンサー1
なぜダメ？
とりわけ、名前空間はサンドボックス化メカニズムです。これにより、システムの残りの部分に影響を与えるかどうかを心配することなく、隔離されたドメイン内の特定の設定を変更できます。
名前空間のマウントを例にしてみましょう。ファイルシステムのマウントは通常、権限のある操作です。任意のファイルシステムをマウントできる場合は、特に選択したset-user-id実行可能ファイルを含むファイルシステムをマウントし、それを実行して昇格攻撃を実行できます。ただし、ユーザーの名前空間内でset-user-id実行可能ファイルを起動すると、その名前空間内の権限のみが増加します。ユーザーネームスペース内のルートユーザーIDは、ネームスペース外の一般ユーザーIDにマップされ、プロセス機能も同様に適用されます。この名前空間に属するリソースに接続されます。
ユーザーの名前空間がない場合は、同様の方法で特権の昇格のために別の種類の名前空間を作成できます。ただし、「権限」がユーザーの名前空間に制限されている場合、これを許可しない理由はありません。実際、これにはいくつかのユースケースがあります。ユーザーの名前空間は権限を制限するだけでなく、特権境界と非権利境界を定義する可能性も作成します。以内に悪意のあるプロセスがサンドボックスを完全に脱出し、サンドボックス自体を掌握するのを防ぐためのネームスペースです。
LWN 記事ネームスペース操作、パート6：ユーザーネームスペースの詳細権限なしで名前空間を作成できるアプリケーションのいくつかは次のとおりです。
機能がネームスペースに与える影響を分離することで、ユーザーネームスペースは、権限のないユーザーが以前にrootユーザーに制限されていた機能に安全にアクセスできるようにすることを約束します。これは最終的に新しいタイプのユーザ空間アプリケーションに対する興味深い可能性を生み出す。たとえば、権限のないユーザーは、root権限なしでLinuxコンテナを実行できるようになりました。Chromeスタイルのサンドボックス達成するために set-user-ID-root ヘルパーを使用する必要はありません。近さ型アプリケーションは動的接続トリックと実装を使用しません。
chroot()アプリケーションベースプロセス分離に使用されます。カーネルのバグを除いて、ユーザーの名前空間を使用して特権カーネル機能にアクセスするアプリケーションは、既存のset-user-ID-rootベースのアプリケーションよりも安全です。ユーザーの名前空間ベースのアプローチでは、アプリケーションが破損しても影響を与えません。より広いシステムに損傷を与えるために使用できるすべての権限。
つまり、ユーザーの名前空間のサポートを追加すると、Linuxにいくつかのセキュリティ上の脆弱性が発生します（一例を挙げると) 一部配布まで権限のないユーザー名前空間の作成はデフォルトで無効になっています。。
資料をお探しの方は、名前空間に関する残りのLWNシリーズこのトピックについて詳しく説明します。