私が正しく理解していれば、Debianパッケージの メンテナスクリプト はroot権限で実行されます。これは、私の予想に反して、悪意のあるパッケージをインストールすると、パッケージ内のコードを実行するユーザーだけでなく、システム全体が侵害される可能性があることを意味すると思います。
質問0:私は正しいですか?
質問1:この脅威を軽減する方法はありますか? (たとえば、postinstallスクリプトが潜在的に問題のある特権を使用しようとした場合に管理者に警告するchrootのような「サンドボックス」にDebianパッケージをインストールするツールはありますか?)
質問2:Debianチームがメインのリポジトリでこの脅威に対処する方法は何ですか?これらのリポジトリにパッケージを寄稿する人々の数を考えると、それは簡単なことではないはずです。
(同じ質問がUbuntuなどのDebianの派生物にも当てはまります。他のディストリビューションがこの問題を処理する方法に関する情報も歓迎します。)
2015年7月27日に追加:受け取った回答を次のように要約できます。
0)はい、問題です。
1)コードを読むか、使用するユーザーとしてソフトウェアをインストールします。後で、手動インストールの苦痛を和らげるかもしれないfakechrootツールがあります。
2)関係する多くのボランティアによるDebianリポジトリの通常のスクリーニング以外に、この問題に特別な注意が払われることはありません。
私は今WhiteWinterWolfの答えを受け入れますが、私はこの問題の良い解決策に興味を持ち続けています。また、他のディストリビューションがこれをよりよく/異なって処理する場合、それも興味深いでしょう。
質問0:正しいですか?
はい。それで合っています。パッケージをインストールするにはルート特権が必要なので、悪意のあるパッケージをインストールすると、悪意のあるコードがルートとして実行されます。
質問2:Debianチームがメインのリポジトリでこの脅威に対処する方法は何ですか?
まず、Debianリポジトリのみ、より正確にはDebian安定したリポジトリのみを使用することをお勧めします。これには2つの理由があります。
次に、ルートプロセスがパッケージのインストールを開始しようとすると、このパッケージが本当にDebianチームによって提供されたものであり、サードパーティによって変更されていないことを確認するために、各パッケージは暗号で署名されています。パッケージに変更を加えると、一連の警告メッセージが表示され、このインストールを続行する前によく考えるよう求められます。
質問1:この脅威を軽減する方法はありますか?
さて、あなたの側にとっては、それは主に実際のニーズと環境に依存します。
もちろん、彼のコメントでetherealfluxが言及したように、実動システムでの新規インストールは、注意深くスクリーニングする必要があります。パッケージを手動で解凍して内容を確認したり、隔離されたテスト環境にインストールして動作を確認したりすることができます。
ただし、別の解決策もあり、主に自分のコメントに対処します "たとえば、共有マシンにテトリスゲームをインストールすると、そのゲームをプレイしていないユーザーのアカウントを危険にさらす理由はありません。」。
ただし、そのためには、パッケージを実際に理解するために少し前に戻る必要があります。
Unix/Linuxの初期の頃は、パッケージはありませんでした(Linuxの場合は、少なくともごくわずか)。アプリケーションをインストールする場合は、最初にソースをダウンロードしてからコンパイルする必要があります。これにより、ソフトウェアのインストールと更新に時間がかかりましたが、それぞれが希望どおりにソフトウェアを構成することができました。
それからパッケージが来ました:そのようなシステムのための最も一般的な設定を含むコンパイル済みソフトウェア。
ここにテトリスゲームの問題があります。これらの「最も一般的な設定」には、ソフトウェアがシステム全体にインストールされることが含まれますが、これはこのシステム全体のインストールですデフォルトでは、これがTetrisをインストールするユーザーが共有環境全体とそのすべてのユーザーを危険にさらす可能性がある理由です。
ユーザーレベルでのソフトウェアインストール
/home
パーティション(独立している場合)でコードの実行が許可されている限り(/etc/fstab
ファイルにnoexec
マウントオプションはありません)、ユーザーは自分のパーティションをインストールできます他のユーザーに影響を与えず、ルート権限を必要とせずに、独自のホームディレクトリにあるソフトウェア。
ただし、そのようなインストールは、上記の「最も一般的な設定」の一部ではないため、パッケージはこの可能性を提供しません。したがって、ユーザーは次のように進める必要があります。
INSTALL
ドキュメントファイルを読み、ソースコードで提供される configure
スクリプト (./configure --help
)で許可されているコンパイルオプションを確認します。具体的には、すべてのディレクトリをホームディレクトリの下に設定する必要があります。たとえば、スクリプトで--prefix
パラメータを使用すると、ソフトウェアをインストールする必要がある場所を簡単に識別できるため、たとえば./configure --prefix=/home/myuser/local
を指定できます。ただし、他のソフトウェアでは、その複雑さと要件に応じて、異なるパラメーターを設定する必要がある場合があります。優れた健全なプロジェクトの場合、これはすべて、提供されているINSTALL
ファイルとconfigure
オンラインヘルプで明確に説明されており、見た目よりも簡単です。make
を実行して休憩を取り、コンパイルが終了したらmake install
を実行するだけです(ルートにsudoすることなく!)。このようなプロセスでの唯一の本当の問題は、このソフトウェアのコンパイルにシステムで利用できない依存関係が必要な場合です(これにより、configure
ステップでエラーメッセージが表示されます。このスクリプトの役割の1つは、すべての依存関係を確認することです。ソフトウェアのコンパイルと実行に必要な要件が満たされている)。依存関係を満たすためにパッケージをインストールするか、ユーザーレベルでパッケージをコンパイルするか、適切なconfigure
パラメータ/環境変数を設定するかを選択できるため、これは再帰的な問題となり、コンパイルツールと最終的なバイナリがすべてを検出できるようになります。が必要だ。
しかし、ついにあなたのユーザーは、他のユーザーに影響を与えたり、スーパーユーザー権限を必要とすることなく、自分のアカウントに完全にインストールされたテトリスを取得します。