Linuxでfakerootはどのようにセキュリティ違反ではないのですか？

この質問からいくつかの非常に良い答えを読んだ後、私はあなたが実際にルートになることの利点を得ることなくあなたがルートであるふりをしたい理由についてまだあいまいです。

これまでのところ、fakerootを使用して、unzip / tarされたときにルートである必要があるファイルに所有権を与えるということを収集できます。私の質問は、なぜあなたはchownでそれができないのですか？

ここでのGoogleグループの議論では、Debianカーネルをコンパイルするにはfakerootが必要であることが指摘されています（特権のないユーザーからそれをしたい場合）。私のコメントは、コンパイルするためにrootになる必要があるのは、おそらく他のユーザーに読み取り権限が設定されていないからだと言っています。もしそうなら、fakerootがコンパイルを許可するセキュリティ違反ではありません（つまり、gccはroot用のファイルを読み取ることができます）？

ここでのこの回答は、実際のシステムコールがユーザーの実際のuid / gidを使用して行われることを示しています。

Linuxでfakerootはどのようにして不要な特権エスカレーションを阻止しますか？fakerootがtarをだましてrootが所有するファイルを作成できる場合、SUIDで同様のことをしてみませんか？

私が集めたものから、rootにビルドしたパッケージファイルの所有者を変更する場合、fakerootが便利です。しかし、あなたはchownでそれを行うことができますので、このコンポーネントがどのように使用されるべきであるかについての私の理解のどこに欠けていますか？

これまでのところ、fakerootを使用して、unzip / tarされたときにルートである必要があるファイルに所有権を与えるということを収集できます。私の質問は、なぜあなたはchownでそれができないのですか？

chown少なくともを使ってそれを行うことはできないので、少なくとも非rootユーザーとしてはできません。（また、rootとして実行している場合は、必要ありませんfakeroot。）これfakerootが、rootを必要とする操作が成功するふりをしながら、rootとして実行されるプログラムを通常のユーザーとして実行できるようにするためのポイントです。

これは通常、パッケージをビルドするときに使用され、インストールされているパッケージのインストールプロセスがエラーなしで実行できるようにします（実行する場合でもchown root:root、またはinstall -o rootなど）。fakerootファイルを与えるふりをした偽の所有権を覚えているので、所有権を見る後続の操作は、実際の所有権の代わりにこれを見る。これによりtar、たとえば、rootが所有するファイルを以降の実行で保存できます。

Linuxでfakerootはどのようにして不要な特権エスカレーションを阻止しますか？fakerootがtarをだましてrootが所有するファイルを作成できる場合、SUIDで同様のことをしてみませんか？

fakerootだましていないtar何もに、それはビルドがこれらの変更は、ビルドをホストしているシステムに影響を取るせることなく行いたい変更内容を保存します。fakerootrootとsuidが所有するファイルを含むtarballを作成する必要はありません。バイナリを持っている場合、通常のユーザーとしてをevilbinary実行するとtar cf evil.tar --mode=4755 --owner=root --group=root evilbinary、を含むtarballが作成evilbinaryされます。ただし、rootとして実行しない限り、そのtarballを抽出してそれらの権限を保持することはできません。ここには特権の昇格はありません。fakeroot権限のあるデ-エスカレーションツール：通常のユーザーとしてビルドを実行できますが、ビルドがルートとして実行された場合の効果を保持し、それらの効果を後で再生できます。「本当の」効果を適用するには、常にルート権限が必要です。fakerootそれらを取得する方法を提供しません。

の使用をfakerootより詳細に理解するために、一般的なディストリビューションビルドには次の操作が含まれることを考慮してください（他の多くの操作と同様）。

• ルートが所有するインストールファイル
• ...
• まだルートが所有しているファイルをアーカイブし、抽出されたときにルートが所有するようにします

ルートでない場合、最初の部分は明らかに失敗します。ただし、fakeroot通常のユーザーとしてで実行すると、プロセスは次のようになります。

• ルートが所有するインストールファイル—これは失敗しますが、fakeroot成功するふりをして、変更された所有権を記憶します
• ...
• まだルートが所有しているファイルをアーカイブします— tar（または使用されているアーカイバが）ファイルの所有権をシステムに尋ねるとき、fakeroot以前に記録した所有権と一致するように回答を変更します

したがって、実際にルートとして実行している場合と同じ結果を取得しながら、ルートにならずにパッケージビルドを実行できます。使用する方fakerootが安全です。システムはユーザーが実行できないことを実行できないため、不正なインストールプロセスがシステムに損害を与えることはありません（ファイルに触れる以外）。

Debianでは、これを必要としないようにビルドツールが改善されており、なしでパッケージをビルドfakerootできます。これはdpkg、Rules-Requires-Rootディレクティブを使用して直接サポートされます（を参照rootless-builds.txt）。

の目的fakeroot、およびルートとして実行するかどうかのセキュリティの側面を理解するには、パッケージングの目的を検討すると役立つ場合があります。システム全体で使用するためにソースからソフトウェアをインストールする場合、次の手順を実行します。

1. ソフトウェアをビルドします（特権なしで実行できます）
2. ソフトウェアをインストールします（rootとして、または少なくとも適切なシステムの場所への書き込みを許可されたユーザーとして実行する必要があります）。

ソフトウェアをパッケージ化すると、2番目の部分が遅れます。しかし、そうするためには、システムではなくパッケージにソフトウェアを「インストール」する必要があります。したがって、ソフトウェアをパッケージ化すると、プロセスは次のようになります。

1. ソフトウェアをビルドします（特別な特権なし）
2. ソフトウェアをインストールするふりをする（これも特別な特権なし）
3. ソフトウェアのインストールをパッケージとしてキャプチャする（同上）
4. パッケージを利用可能にする（同上）

これで、ユーザーはパッケージをインストールしてプロセスを完了します。これは、rootとして実行する必要があります（または、適切な場所に書き込むための適切な特権を持つユーザー）。これは、遅延特権プロセスが実現される場所であり、特別な特権を必要とするプロセスの唯一の部分です。

fakeroot ルートとして実行せずにソフトウェアインストールプロセスを実行し、その動作をキャプチャできるようにすることで、上記の手順2および3を支援します。

いや 偽のルートを使用すると、権限操作およびレポートツールを実行でき、一貫してレポートされます。ただし、実際にはこれらの権限は付与されません。あなたがそれらを持っているように見えます（偽）。環境の外部には何も変わりません。

ユーザーが設定できなかった所有権とアクセス許可を含むディレクトリ構造を作成する場合は、tar、zip、またはその他のパッケージを作成すると便利です。

権限を実際に昇格させるのではなく、偽物です。他の方法では実行できなかった（削除、書き込み、読み取り）ことはできません。パッケージを（理論的には）それなしで作成できます。偽のレポート（ls）を入手できます。

これは、セキュリティの欠陥ではありません。アクセスやそれなしではできないことを許可しないからです。特権なしで実行されます。それは用量すべてがにインターセプトの呼び出しでchown、chmodそれが起こったであろうものを記録する以外は、などこれは、それらを無操作になります。またstat、他のコマンドが実行されたかのように、独自の内部データベースからアクセス許可と所有権を報告するように、などへの呼び出しをインターセプトします。これは、ディレクトリを圧縮すると偽のアクセス許可が付与されるため、便利です。その後、rootとして解凍すると、権限が現実のものになります。

以前に読み取り/書き込みができないファイルは、読み取り/書き込みができません。作成された特別なファイル（デバイスなど）には特別な権限はありません。（別のユーザーへの）set-uid、ファイルはset-uidしません。他の特権の昇格は機能しません。

これは一種の仮想マシンです。一般に、仮想マシンはすべての環境/ OSをシミュレートできますが、ホストに対しては何もできません。他のアプリケーションはできません。仮想マシン内では、何でもできるように見えます。セキュリティシステムを同じまたは異なるように再発明できますが、仮想環境を実行しているプロセスのユーザー/グループが所有するリソースとして、ホスト上にすべて存在します。

ここにはすでに2つの優れた非常に詳細な回答がありますが、元の fakeroot マニュアルページ^1の導入段落で実際にかなり明確かつ簡潔に説明されていることを指摘しておきます。

fakerootは、ファイル操作のためのルート特権を持っているように見える環境でコマンドを実行します。これは、ユーザーがルート許可/所有権を持つファイルを使用してアーカイブ（tar、ar、.debなど）を作成できるようにするのに役立ちます。fakerootがなければ、適切な許可と所有権でアーカイブの構成ファイルを作成し、それらを圧縮するためにルート権限が必要になります。または、アーカイバーを使用せずにアーカイブを直接構築する必要があります。

Fakerootを使用すると、非ルートユーザーがルート所有ファイルを含むアーカイブを作成できます。これは、Linuxでのバイナリソフトウェアパッケージの生成と配布の重要な部分です。を使用しないfakeroot場合、実際のルートとして実行中にパッケージアーカイブを生成し、正しいファイルの所有権と権限を含める必要があります。それはセキュリティ上のリスクになります。潜在的に信頼されていないソフトウェアの構築とパッケージ化は、root権限で行われた場合、大きな露出です。のおかげfakerootで、非特権ファイルを持つ非特権ユーザーは、ルート所有権を持つファイルを含むアーカイブを生成できます。²

ただし、ファイルがEXTRACTEDされるまで、アーカイブ内の実際にはルートによって所有されるものはないため、セキュリティ上のリスクではありません。そして、それでも、ファイルは特権ユーザーによって実行された場合にのみ、ルート権限が変更されずに抽出されます。「ルート」ファイルを含む- アシストアーカイブが特権ユーザーによって抽出されるステップは、「偽の」ルートが最終的に実現する場所です。その時点まで、実際のルート特権は取得またはバイパスされません。fakeroot

ノート

1. Fakerootはfakeroot、やを含むfakeroot-ng、インストールされているかのように見せかけるいくつかの競合他社/模倣者を生み出しましたpseudo。しかし、IMHOの「イミテーター」のマニュアルページも、この質問のポイントに正しく到達することについてほぼ同じくらい明確ではありません。オリジナルの唯一のfakerootOGに固執する

2. 他のディストリビューション/パッケージングシステムは、パッケージアーカイブでルート所有権を使用しないことでこれを克服しています。たとえば、Fedoraでは、を必要とせずに、権限のないユーザーがソフトウェアをコンパイル、インストール、およびパッケージ化できますfakeroot。それはすべてユーザーの$HOME/rpmbuild/スペース内で行われ、通常の特権のあるステップはmake install（--prefixやなどのメカニズムを介してDESTDIR）$HOME/rpmbuild/BUILDROOT/一種の「fakechroot」スペースと見なされる階層にリダイレクトされます（実際には使用しませんfakechroot）。

   ただし、の間make installでも、すべては特権のないユーザーとして実行され、所有されます。抽出されたファイルの所有権とアクセス権がに設定されますroot,rootと0644（または0755パッケージ定義（に上書きされない限り、デフォルトでは実行可能ファイルの）.spec彼らは最終的なパッケージの中にメタデータとして保存されていた場合には）ファイル。rpmパッケージの（特権）インストールプロセスまで実際には権限や所有権が適用されないfakerootため、パッケージ化中にルートも必要もありません。しかしfakeroot、実際には同じ結果への単なる別の道です。