fakerootはどのようにLinuxのセキュリティホールを構成しませんか？

これまで私が収集できるのは、ファイルの解凍/圧縮時にroot権限を必要とするファイルの所有権を付与するためにfakerootが使用されることです。私の質問はなぜチャウンでこれを行うことができないのですか？

chown少なくとも、root以外のユーザーとしてはできません。 （rootとして実行している場合は必要ありませんfakeroot。）これがポイントですfakeroot。ルートとして実行したいプログラムは、rootを必要とするタスクが成功したかのように偽装しながら、通常のユーザーとして実行できるようにすることです。

これは通常、インストールされているパッケージのインストールプロセスがスムーズに進行できるようにパッケージをビルドするときに使用されます（実行されている場合でもchown root:root）install -o root。fakerootファイルの誤った所有権を提供するふりをするので、所有権を確認する後続の作業では、実際の所有権の代わりにこの所有権を表示します。tarたとえば、これにより、後続の実行でファイルをルート所有として保存できます。

fakerootはLinuxで不要な特権の上昇をどのように防ぐのですか？fakerootがtarをだましてルートに属するファイルを生成できる場合は、SUIDを使用して同様のことをしてみてはいかがでしょうか？

fakeroot何もするためにトリックを書かずtar、ビルドをホストしているシステムに変更が適用されないように、ビルドで必要な変更を維持します。ルートとsuidが所有するファイルを含むタールボールを作成する必要はありませんfakeroot。バイナリがあり、evilbinary通常のユーザーとして実行すると、rootとsuidが所有するタールボールを含むタールボールが作成されます。ただし、rootでこれを行わないと、tarballを抽出してこれらの権限を維持することはできません。ここでは特権の上昇はありません。特権ですtar cf evil.tar --mode=4755 --owner=root --group=root evilbinaryevilbinaryfakerootダック-アップグレードツール：rootとして実行するときにビルドの効果を維持し、その効果を後で再生できるようにしながら、一般ユーザーとしてビルドを実行できます。 「実際の」アプリケーションエフェクトには常にルートアクセスが必要です。fakerootこれを達成する方法は提供されていません。

使い方を詳しく理解するには、fakeroot一般的なリリースビルドに次のタスクが含まれることを検討してください。

• rootが所有するインストールファイル
• ...
• まだルートが所有しているファイルをアーカイブし、抽出時にルートが所有します。

ルートでない場合、最初の部分は明らかに失敗します。fakerootただし、以下で実行すると

• rootが所有するファイルのインストール - 失敗したがfakeroot成功したふりをします。変更された所有権を覚えてください
• ...
• まだルートが所有しているこのファイルを保持します。tar（または使用しているアーカイブが何であれ）システムにファイルの所有権が何であるかを尋ねる場合は、fakeroot以前に記録された所有権と一致するように答えを変更します。

したがって、実際にrootとして実行するのと同じ結果を得ながら、ルートなしでパッケージビルドを実行できます。より安全な使用fakeroot：システムはユーザーが実行できない操作を実行できないため、悪意のあるインストールプロセスによってシステムが損傷することはありません（ファイルに触れることを除く）。

Debian ではビルドツールが改善され、この機能は不要になりました。ビルドパッケージはそうではありません。fakeroot。これはディレクティブをdpkg介して直接Rules-Requires-Rootサポートされます（参照：rootless-builds.txt）。

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

1. ソフトウェアビルド（許可なく実行可能）
2. ソフトウェアのインストール（ルートまたは少なくとも適切なシステムの場所に書き込むことができるユーザーとして実行する必要があります）

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

1. ソフトウェアビルド（特別権限なし）
2. ソフトウェアをインストールするチャック（やはり権限なし）
3. ソフトウェアのインストールをパッケージとしてキャプチャ（同じ）
4. パッケージを使用可能にする（同じ）

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

fakerootこれは、rootとして実行することなくソフトウェアのインストールプロセスを実行し、その動作をキャプチャできるようにすることで、上記の手順2と3を実行するのに役立ちます。

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

これは、所有権と特権のあるディレクトリ構造を作成したいが、ユーザーがそのディレクトリ構造を設定できず、tar、zip、または他の方法でパッケージ化できる場合に便利です。

それ確かに本当に権限を拡大するなら、それは偽です。ユーザーができない操作（削除、書き込み、読み取り）は実行できません。 （理論的に）それなしでパッケージを製造することができます。lsそうしないと、誤った報告（）が発生する可能性があります。

これはセキュリティ上の欠陥ではないため確かにアクセスを許可するか、それなしでは実行できないすべての操作を許可します。実行する権限は必要ありません。それがすることは、chownなどへの呼び出しを傍受するだけです。chmod起こり得ることを記録する点を除いては機能しません。またstat、他のコマンドと同様に、独自の内部データベースから権限と所有権を報告するためにピアへの呼び出しを傍受します。ディレクトリを圧縮すると偽の権限が発生するため、これは便利です。その後、rootに解凍すると権限が実際になります。

以前に読み取れなかったか書き込めなかったファイルは、まだ読み書きできません。生成された特殊ファイル（デバイスなど）には特別な権限がありません。 （他のユーザーに）set-uidのファイルはset-uidになりません。他の権限の上昇は効果がありません。

これは一種の仮想マシンです。通常、仮想マシンはすべての環境/オペレーティングシステムをエミュレートできますが、ホスト上の他のアプリケーションが実行できない操作を実行することはできません。仮想マシンでは何でもできるようです。セキュリティシステムは同じまたは異なる方法で再設計できますが、すべて仮想環境のプロセスを実行しているユーザー/グループが所有するリソースとしてホストシステムに存在します。

ここにはすでに2つの素晴らしい、非常に詳細な答えがありますが、指摘したいと思います。オリジナル fakeroot マニュアルページ¹実際、非常に明確で簡潔に説明されています。

近さファイル操作に対するroot権限を持つように見える環境でコマンドを実行します。これは、ユーザーがroot権限/所有権を持つファイルを含むアーカイブ（tar、ar、.debなど）を作成できるようにするのに役立ちます。いいえ近さ正しい権限と所有権を使用してアーカイブの構成ファイルを作成し、それをパッケージ化するには、rootアクセス権が必要な場合、またはアーカイバーを使用せずにアーカイブを直接ビルドする必要があります。

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

しかし、アーカイブには何もないため、セキュリティ上のリスクはありません。実際にファイルが削除されるまでルートが所有します。抜粋。それにもかかわらず、権限を持つユーザーが実行した場合、root権限が破損していない場合にのみファイルを抽出できます。fakeroot特権ユーザーが「ルート」ファイルを含むセカンダリアーカイブを抽出するこの段階では、「偽の」ルートがついに本物になります。その時点までは、実際のルート権限を取得または迂回しませんでした。

ノート

1. fakerootFakerootは、以下を含むインストールされたふりをする多数の競合他社/模倣製品を作成しました。fakeroot-ngそしてpseudo。しかし、IMHO、両方の「模倣犯」のマニュアルページでは、問題のポイントを明確に明らかにしません。独創性にこだわるユニークなfakerootOG

2. 他の流通/包装システムは、簡単に言えばこの問題を克服します。いいえパッケージアーカイブでルート所有権を使用します。たとえば、Fedoraでは権限のないユーザーがfakeroot。 "fakechroot"空間の階層（実際の使用なし）。$HOME/rpmbuild/make install--prefixDESTDIR$HOME/rpmbuild/BUILDROOT/fakechroot

   しかし、その間でも、すべてmake installは権限のないユーザーとして実行および所有されます。デフォルトでは、抽出されたファイルの所有権と権限は、パッケージ定義（）ファイルでオーバーライドされない限り、root,rootand 0644（または0755実行可能ファイルの場合）に設定され.spec、その場合は最終パッケージにメタデータとして保存されます。 rpmパッケージ（権限）のインストールプロセスまでは実際には権限や所有権が適用されないため、fakerootパッケージングプロセスではルートやルートは必要ありません。しかし、これはfakeroot実際には同じ結果を得るための別のパスです。