bwrap ddsec
1.0.0
バブルラップの特権のないサンドボックスプロファイル
Systemd-nspawn、dockeretc。などの多くのコンテナ実行時間ツールは、システム管理者にインフラストラクチャを提供し、コンテナを実行するためのオーケストレーションツール（Kubernettesなど）を提供することに焦点を当てています。
これらのツールは、そのようなアクセスをホストに完全な特権を持つルートシェルに変換することが些細なことであるため、特権なしでユーザーに提供するのに適していません。
Linuxカーネルレベルには、「ユーザーネームスペース」ユーザー名スペースと呼ばれる分離システムがあり、特権のないユーザーがコンテナの機能を使用できるようにしようとします。大きな進歩は達成されていますが、この点ではまだ懸念があり、Centos / Red Hat Enterprise Linux 7、Debian Jessieなどのいくつかの生産分布で特権のないユーザーには利用できません。
たとえば、CVE-2016-3135を参照してください。これは、ユーザーが導入したローカルルートの脆弱性です。今年3月の出版物はもっと議論しています。
BubbleWrapは、ユーザー名スペースのサブセットの全体的な実装と見なすことができます。サブセットに重点を置く - 以前のCVEに特に関連しているBubbleWrapは、iPtablesの制御を許可していません。
元のBubbleWrapコードは、ユーザー名スペースの前に存在していました。XDG -Appヘルパーコードを継承し、Linux-User-Chrootによって妨害されます。
このツールのメンテナーは、その分布にインストールされている典型的なソフトウェアと組み合わせて使用しても、特権のエスカレーションを許可しないと考えています。ただし、サービスの拒否攻撃を実行するためにログインしたユーザーの能力を高めることができます。
特に、BubbleWrapはPR_SET_NO_NEW_PRIVSを使用してSetUidバイナリを無効にします。これは、Chrootsのようなものから出る従来の方法です。
このプログラムは、次のような操作をルート化しないすべてのコンテナツールで共有できます。
BWRAP-OCI特権を持たないFlatpak RPM-Ostreeは、Kubernetes / Onshiftクラスターでこれを利用できるようにしたいと思います。特権のないユーザーがコンテナの機能を使用する能力を持つことは、インタラクティブおよび類似の浄化シナリオの実現を大幅に促進します。
BubbleWrapは、ルートがホストには見えないTMPFにある新しい完全に空のアセンブリ名スペースを作成することで機能し、最後のプロセスが終了すると自動的にクリーニングされます。次に、コマンドラインオプションを使用して、ルートファイルシステムとプロセス環境、および名前空間で実行するコマンドを構築できます。
ソースコードには、より大きなデモンストレーションコマンドシーケンスがありますが、ここにはファイル /USRを再利用する新しいシェルを実行する小さなバージョンがあります。
bwrap -ro-bind /usr /usr-symlink usr /lib64 /lib64-proc /proc - dev /dev-share-pidこれは不完全な例ですが、実証的な目的に役立ちます。より多くの場合、ホストファイルシステムツリーを使用してコンテナを作成する代わりに、クルートにサインアップする必要があります。そこでは、LIB64-> USR/LIB64シンボリックリンクを作成する代わりに、TMPFSは宛先ROOTFですでに作成されている可能性があります。
BubbleWrapの目的は、Sand Boxでアプリケーションを実行することです。SandBoxは、開始ディレクトリなどのオペレーティングシステムまたはユーザーデータへのアクセスが制限されています。
BubbleWrapは常に新しいアセンブリ名スペースを作成し、ユーザーはサンドボックスにファイルシステムのどの部分を表示するかを正確に指定できます。指定されたこれらのディレクトリはいずれも、所定のフォームでマウントされ、読み取りのみを行うことができます。
さらに、これらのカーネル関数を使用できます。
ユーザー名スペース（clone_newuser）：これは、現在のUIDとサンドボックスを除くすべてを隠しています。また、UID / GID値がサンドボックスにあるものを変更することもできます。
IPC名スペース（clone_newipc）：サンドボックスは、SYSV共有メモリや信号など、すべての異なる形式のCPIの独自のコピーを取得します。
PID名スペース（clone_newpid）：サンドボックスには、サンドボックスの外にプロセスが表示されません。さらに、BubbleWrapは、コンテナ内のPID1些細なものを実行して、砂の箱に子供を刈り取る要件を処理します。これにより、現在Docker PID 1の問題として知られているものが回避されます。
スペースdehttp：//linux.die.net/man/2/cloneネットワーク名（clone_newnet）：サンドボックスにはネットワークが表示されません。代わりに、逆ループデバイスのみを備えた独自のネットワーク名スペースがあります。
UTS名Space（clone_newuts）：サンドボックスには独自のホスト名があります。
SECCOMPフィルター：テストゾーンで実行できるシステムへの呼び出しを制限するSECCOMPフィルターが通過できます。詳細については、SecCompを参照してください。
Firejailは、BubbleWrapがSetUidツールと多くの特定のデスクトップサンドボックス機能を組み合わせているという意味に分割される前に、フラットパックに似ています。たとえば、FirejailはPulseaudioを知っていますが、Bubblewrap no。
BubbleWrapの著者は、現在のFlatpakの場合のように、小さなSetUidプログラムを監査し、Pulseaudioフィルタリングなどの特性を特権のないプロセスとして維持する方がはるかに簡単であると考えています。
さらに、@CGWALTERSは、ユーザーがルートを操作し、システム管理者がシステムを構成できるという無数の方法を操作しなければならない無数の方法を考えると、白いリストにファイルルートを含めようとすることは悪い考えであると考えています。 BubbleWrapアプローチは、cap_sys_adminなどの特定のLinux機能のみを保持することですが、呼び出しUIDなどのファイルシステムに常にアクセスします。これにより、tocttou攻撃やその他の攻撃が完全に閉じられます。
Sandstorm.ioは、サンドボックスを構成する特権のないユーザー名のスペースを必要としますが、SetUIDモードでの動作にも簡単に適応できます。 @cgwaltersは、そのコードは非常に優れていると考えていますが、Bubblewrapで統合することはまだ理にかなっています。ただし、 @Kentonv（Sandstormから）は、これは原則として理にかなっていますが、変化のコストは今のところ実際の利点を超えていると感じています。この決定は将来的に再評価される可能性がありますが、今日では積極的に適用されていません。
RUNCは現在、RUNCのインストール中に他の特権を必要とせずに、ルートなしでコンテナサポートに取り組んでいます（setUIDではなく特権のないユーザー名スペースを使用）、コンテナの作成と管理。ただし、RUNCを使用する標準モードは、rootによって呼び出されるように設計されているSystemD nspawnに似ています。
BubbleWrapの著者は、RuncとSystemD-NspawnはSetUidになるように設計されておらず、そのような方法を認めることからはほど遠いと考えています。ただし、ルートのないコンテナを使用すると、RuncはBubbleWrapによって認められた特定のユースケースに準拠できます（完全で標準化されたOCI実行時間であるという追加の利点があります）。
BinctrはRUNCの封筒にすぎないため、すべての設計補償を継承しています。
