web-dev-qa-db-ja.com

HomebrewがMacのセキュリティに与える影響

私は( herehere )を読んで、Homebrew(Unixパッケージマネージャー)はMacの重大なセキュリティリスクであると述べています。 Homebrewがrootユーザー権限なしで/usr/local/binを書き込み可能にするため、攻撃が許可されます。これにより、別のHomebrewプロセスが悪意のあるプロセスをこのディレクトリツリーに書き込むことができます。シェルのパスでは、デフォルトで/usr/local/binツリーの前に/usr/binが追加されます。そのため、攻撃者は悪意のあるバイナリを挿入して時計を変更したり、管理者のパスワード(悪意のあるSudoなど)を盗んだりする可能性があります。

これらの脆弱性を知っている人はいますか?エンドユーザーの端末(MacBook w/OSXなど)のセキュリティに影響を与えることなく、重要なUnixコマンドにアクセスできるより良い方法はありますか?/optにroot権限を使用してインストールするパッケージマネージャーに依存するMacportsを使用していますか? Unix Shellのすべての作業をVirtual BoxやVMWareなどのエミュレータで実行しますか?

製造から始まり、ソフトウェアアプリがインストールされるとすぐに、多くのセキュリティホールがあることを知っています。これに関するセキュリティ専門家のベストプラクティスに非常に興味があります。

UPDATE 2018-11-07

私はmacportsメーリングリストで確認し、迅速で詳細な返信を受け取りました。残念ながら、Homebrewフォーラムからの機能の詳細を含む応答はありません。この時点で、macportsの方がセキュリティ機能が優れていると思います。常にどこかに穴が開いている可能性があり、本当に安全であるために、これらのオープンソースアプリケーションを自己完結型のエミュレートされたコンテナーにインストールすることを検討します。たとえば、VirtualBox、VMWare、Parallelsを使用します。このようにして、セキュリティ問題がある場合、それは封じ込められ、Macキーチェーンやその他の重要なデータへのアクセスを公開しません。

macportsメーリングリストから更新を受信しました

Webページに掲載されているインストーラーパッケージを使用してMacPortsをインストールするには、管理者パスワードが必要です。インストールするファイルとディレクトリはrootが所有しているため、管理者は誰も変更できません。また、MacPortsが後で使用する「macports」と呼ばれる通常の非特権ユーザーアカウントも作成します。

この方法でインストールされたMacPortsを使用するには、管理者パスワードも必要です。 MacPortsポートがインストールするファイルは通常ルートによって所有されますが、個々のポートはそれについて独自の決定を行うことができます。たとえば、データベースサーバーポートは、データベースサーバーの実行中に使用される特別なユーザーアカウントを作成し、データベースサーバーが書き込むファイルが存在できる空のディレクトリをインストールし、そのディレクトリの所有者がその新しいユーザーアカウントに設定されます。

「Sudo」を使用して「port」コマンドを呼び出し、管理者パスワードを入力すると、MacPortsは権限のない「macports」ユーザーに切り替えます。その時点では、root権限はなくなっているため、これを実行しようとする悪意のあるportfileがコミットされても、ビルドディレクトリ外のファイルを変更することはできません。 MacPortsは、ルートアクセスを必要とする処理を実行すると、ルート特権に昇格します。たとえば、実際にファイルを/ opt/localプレフィックスにインストールする最後のステップです。

ルートアクセスを使用しないように構成されたソースからMacPortsを構築することは可能であり、その場合、上記の保護は得られません。これを行うことはお勧めしません。

MacPortsは、各ポートがインストールするファイルを追跡し、1つのポートが別のポートのファイルを上書きすることを許可しません(ユーザーが-fフラグを使用してこれを要求しない限り、ユーザーはこのフラグを常用しないでください)。

別の投稿

また、homebrewは、動作方法をかなり完全に再ハッシュしなければ、この程度のセキュリティを提供するように突然変更することができず、/ usr/localにインストールすることのほとんど/多く/すべての「利点」は、人気を高めるために提供されたものは完全に失われ、おそらくこの変更に対応するために、式の多く/ほとんど/すべてを書き直す必要があります。現在、それらの多くは、物事が/ usr/localに自動的に見つかると想定しています。

homebrewは「簡単」であるため、人気があります。/usr/localにあるファイルは、コンパイラやシェルの介入なしに見つかります。ただし、これには費用がかかります。

MacPortsは、特定のインクルードパス、ライブラリパス、実行可能パスを明確に含めるために、より多くの作業を必要とします。

6
Nick

/etc/pathsでパスの順序を変更して、このような悪意のある動作を防ぐことができます。ただし、$PATHはシェルスクリプトでオーバーライドできます(.bash_profileまたは.zshrcなど)。これらも確認/変更してください。

Macportsについて-信頼されていないソフトウェアを最小限の権限でユーザー空間で実行することを好むので、Homebrewの方が適しています。

Unix Shellについて-信頼の連鎖を構築するだけです。つまり、信頼できる端末で信頼できるシェルを使用します。さらに、Patrick Wardleの tools を使用してMacを強化しました。これらはオープンソースであり、必要なネットワークおよびシステムアクセスコントロールを提供するためです。

0
odo