Linuxでfakerootがセキュリティ違反ではないのはなぜですか？

Question

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

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

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

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

Linuxでfakerootはどのようにして不要な特権の昇格を停止しますか？ fakerootがtarをだましてrootが所有するファイルを作成できる場合は、SUIDで同様のことをしてみませんか？

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

Stephen Kitt · Accepted Answer

これまでのところ、私が収集できるのは、fakerootを使用して、ファイルをunzip/tarしたときにrootになる必要があるファイルに所有権を与えることです。 私の質問です、なぜあなたは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をだまして何もしないようにしません。ビルドをホストしているシステムで変更を有効にせずに、ビルドが加えたい変更を保持します。 rootとsuidが所有するファイルを含むtarballを作成するためにfakerootは必要ありません。バイナリevilbinaryがある場合、tar cf evil.tar --mode=4755 --owner=root --group=root evilbinaryは、通常のユーザーとして、rootが所有するevilbinaryとsuidを含むtarballを作成します。ただし、rootで実行しない限り、そのtarballを抽出してそれらの権限を保持することはできません。ここでは特権の昇格はありません。 fakerootは特権de-escalationツールです。通常のユーザーとしてビルドを実行しながら、ビルドが持っていた場合の影響を維持できます。ルートとして実行され、それらの効果を後で再生することができます。「実際に」効果を適用するには、常にroot権限が必要です。 fakerootはそれらを取得する方法を提供していません。

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

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

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

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

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

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

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

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

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

ソフトウェアをビルドします（特別な権限はありません）
ソフトウェアをインストールするふりをします（ここでも特別な権限はありません）
ソフトウェアのインストールをパッケージとしてキャプチャする（同上）
パッケージを利用可能にする（同上）

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

fakerootは、ルートとして実行しなくても、ソフトウェアのインストールプロセスを実行し、その動作をキャプチャできるようにすることで、上記のステップ2と3を支援します。

ctrl-alt-delor · Answer

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

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

それはしない本当に権限を昇格させます、それは偽物です。他の方法では実行できなかった操作（削除、書き込み、読み取り）はできません。パッケージなしで（理論的には）パッケージを作成できます。それなしで偽のレポート（ls）を取得する可能性があります。

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

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

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

FeRD · Answer

ここにはすでに2つの良い、非常に詳細な答えがありますが、originalの紹介段落fakeroot manページ ¹ 実際にそれをかなり明確かつ簡潔に説明しています：

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

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

ただし、ファイルが[〜＃〜]抽出されるまで、アーカイブ内の何も実際にはrootが所有していないため、セキュリティリスクではありません[〜＃〜] [〜＃〜]。それでも、特権ユーザーがファイルを実行した場合、ファイルはルート権限がそのままの状態でのみ抽出されます。そのステップ—「ルート」ファイルを含むfakeroot- assistedアーカイブが特権ユーザーによって抽出される場所—「偽の」ルートが最終的に本物になる場所です。その時点までは、実際のroot権限が取得またはバイパスされることはありません。

ノート

Fakerootは fakeroot-ng および fakeroot を含む、インストールされている場合はpseudoになりすます競合/模倣者を生み出しました。しかし、IMHOも「模倣者の」manページも、この質問の要点を正しく理解することとほぼ同じくらい明確です。オリジナルのfakeroot O.G.
他のディストリビューション/パッケージングシステムは、パッケージアーカイブでroot所有権を使用するだけでしないことで、これを克服しています。たとえばFedoraでは、fakerootを必要とせずに、権限のないユーザーがソフトウェアをコンパイル、インストール、およびパッケージ化できます。これはすべてユーザーの$HOME/rpmbuild/スペース内で行われ、make installのような通常の特権ステップは--prefixやDESTDIRなどのメカニズムを介して$HOME/rpmbuild/BUILDROOT/にリダイレクトされます一種の「偽ルート」空間と見なすことができる階層（実際にはfakechrootを使用しない）。

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