PHPファイルの所有者としてsuexecでPHPスクリプトを実行することのセキュリティ問題
私はsuexecを使用して、PHPスクリプト（およびその他のCGI/FastCGIアプリ）が関連する仮想ホストに関連付けられたアカウント所有者として実行されるようにしています。これにより、各ユーザーのスクリプトが読み取られないように保護できます。 /他のユーザーによる書き込み。
しかし、これは別のセキュリティホールを開くことに気づきました。以前は、Webサーバーは、ユーザーのファイルへの読み取り専用アクセス権を持つ非特権ユーザーとして実行されていました（ユーザーが何らかの理由でファイルのアクセス許可を変更した場合を除く）。これで、Webサーバーはユーザーのファイルに書き込むこともできます。
そのため、さまざまなユーザーが互いのスクリプトを利用するのを防ぎましたが、一部のアプリケーションにリモートコードインジェクションの脆弱性がある場合に、そのユーザーのすべてのユーザーへの読み取りアクセスだけでなく書き込みアクセスもできるようにしました。スクリプトとウェブサイト。
どうすればこれに対処できますか？
私が持っていたアイデアの1つは、システム内のユーザーアカウントごとに2つ目のユーザーアカウントを作成して、各ユーザーが独自のユーザーアカウントを持ち、すべてのスクリプトが別のユーザーアカウントで実行されるようにすることです。しかし、それは面倒なようです。
PHP Webサーバーのアクセス許可の下で実行することは必ずしもより良いまたはSuPHPを使用するよりも悪い。それはただ異なるです。最初のモデルは所有者をWebサーバーから分離しますが、 2番目のモデルは、所有者（およびそのPHPコード）をマシン上の他のすべてのユーザーから分離します。
SuPHPを使用しても、必ずしも全体的なセキュリティが向上するわけではなく、リダイレクトされるだけです。侵入を防ごうとする代わりに、サイトを互いに隔離しているのです。正当な理由は、特に共有ホスティング環境では、以前のセキュリティモデルが機能していなかったということです。ユーザーは、Webアプリケーションが機能するようにすべてにワールド書き込み権限を設定することで、セキュリティに絶えず穴を開けました。 1つのアカウントでのセキュリティ侵害は、サーバー上の他のすべてのアカウントにすぐに転移します。
そのため、代わりに、大規模な共有ホスティング環境でsuPHPなどのツールを使用して、ユーザーとそのPHPアプリケーションの間の障壁を取り除き、代わりにユーザーとその隣人の間の障壁を構築するのが一般的です。 。
したがって、この場合、securityを提供せず、separationを提供します。 -）。残念ながら、suPHPでは、実行する予定のユーザーがファイルを所有する必要があるため、別のFTPユーザーを作成するのは面倒です。 suPHPユーザーとFTPユーザーの間で常にファイルをchownする必要があります。
代わりに、役割を選択する必要があります。サイトを保護するか、サーバーを保護します。サイトを保護したい場合は、Webサーバーをコンテンツ所有者から分離する必要があります。これは正しく維持するためのやや複雑な関係であるため、共有ホスティング環境にはお勧めしません。代わりに、serverをユーザーから保護する場合は、suPHPを使用して、ユーザー（およびそのコード）をサーバー上の他のユーザーから分離します。 。この場合、ユーザーは自分のセキュリティに責任があります。頑張って、ユーザー！技術的には、は安全なPHPアプリケーション）を持つことが可能です-少なくとも理論的には。
まず、ファイルの所有者が書き込みアクセス権を持っている必要がない場合は、ファイルの所有者にファイルを与えないでください。これを行うには、UNIXのアクセス許可の最初の数を設定します。これは、rootのみがファイルへの書き込みアクセス権を持つことを意味します。彼らがファイルをアップグレードする必要があるとき、これは非常に迷惑ですが、あなたは彼らが書き込みアクセス権を持つべきではないと言いました..。
次に、特定のユーザーとしてスクリプトを実行します。 open_basedirを使用してファイルにロックされている場合、ファイルを書き込めれば問題ありません。ハッキングがあると、そのユーザーのファイルのみが破壊されます。 open_basedirがなくても、別の問題である777権限を持つファイルがない限り、ファイルにしか書き込むことができないはずです。
第三に、多くのWebサイトは、少なくとも特定のファイル/フォルダーへの書き込みアクセスを必要とします。たとえば、Wordpressは、ファイルがアップロードされた場合に備えて書き込む必要があります。Webサイトへの書き込みアクセスは、適切に管理していれば必ずしもセキュリティホールではありません。
suexecは非常に良いスタートであり、open_basedirは、書き込みアクセス権を持つユーザーが定義されたディレクトリにとどまるようにします。
suexecは、あなたが本質的に共有されているホスティング環境にいるという事実を回避するための恨みとして常に私を驚かせました—所有ユーザーとして信頼できないリクエストがスクリプトを呼び出すことを許可することは非常に悪いです（そしてどのようにWordPress =インストールはルート化されます）—専用ホストを使用している場合、結局のところ、すべてのファイルをモード0777に設定することはありません。ファイルがまだ残っているため、書き込みアクセスを削除するだけでは役に立ちません所有そのユーザーによるので、最終的には書き込み可能です。同じ理由で、2人の別々のユーザーがいることもあまり役に立ちません。
私の考えでは、正しい解決策は、非特権ユーザーとしてスクリプトを実行することですが、スクリプトをchroot —おそらくFastCGIは、ここでは良い解決策になるでしょう…fcgiプロセスがchrootされているが、Webサーバーはそれが作成するソケットの場所を知っています。
これはそれ自体が「答え」ではないことは理解していますが、以前にこれを思い付いて実装したことがある人にお金をかけ、おそらくsuexec自体のパッチとしても使用します（ForceSUExecUIDおよびForceSUExecGIDオプションを想定します。仮想ホストごとに適用…）