記述されたWebアプリケーションで以下を実行するための8進数形式の完璧な最小限の権限は何ですか?
これが私の提案と正当化です
今、私は2つのことに興味があります:
「Webアプリケーション」がサーバー(Apache、nginxなど)で実行され、何らかの動的スクリプト言語(PHP、Rubyなど)で記述されていると想定すると、「ユーザー」が誰であるかについて誤解があります。
ユーザーは、アプリケーションにログインしているユーザーではありません。つまり、アプリケーションでのユーザーの役割(管理者など)は、シナリオとはまったく関係ありません。ユーザーは、プロセスが実行されるLinuxシステムユーザーです。あなたのウェブサイトのコードはたった一人のユーザーとして実行されます-それはあなたのウェブサーバーのユーザーかもしれません(これは本当に良いことではありません)、あるいはあなたのサイトに固有のユーザーかもしれません(はるかに良いです)。
Linuxでは、ユーザーはグループに属しています。ユーザーを別のグループに追加して、そのグループに特権を割り当てることができます。
適切な設定では、サーバーを1人のユーザーとして実行し(このユーザーを「webserver」と呼びます)、動的スクリプト言語を(FastCGIを介して)独自のユーザーとして実行します(サイトごとに1人のユーザー-最初のユーザーを「site1」と呼びましょう) 。
ファイルを提供するには、ウェブサーバーがファイルにアクセスでき、スクリプト言語がファイルにアクセスできる必要があります。つまり、「site1」と「webserver」はファイルを読み取ることができる必要があります。ただし、ファイルを「所有」できるのはそのうちの1つだけです。所有者は「ユーザー」です(ユーザー、グループ、その他)。また、ディレクトリへの書き込み(およびディレクトリが書き込んだファイルの読み取り)ができるスクリプト言語も必要です。したがって、ユーザー「site1」には読み取りおよび書き込み権限が必要です。グループおよびその他のアクセス許可をできるだけ制限したいので、「所有者」は「site1」になり、対応するユーザーのアクセス許可は読み取りと書き込みになります。
Webサーバーの権限を別の「ユーザー」として指定することはできないため、「webserver」を「site1」グループに追加します(もちろん、「site1」と「webserver」の両方を含む別のグループを作成できます。すべてこのグループのメンバーには同じ権限が付与されます。(ユーザー、グループ、その他のセットの)最も緩い権限が特定のユーザーに適用され、権限が決定されます。
適切な設定では、動的言語の実行権限をファイルに持たせる必要がないことに注意してください。ファイルは直接実行されるのではなく、インタープリターに読み込まれます。通常のスクリプト(何も書き込まないスクリプト)を実行するには、読み取り権限のみが必要です。
ディレクトリの「実行」権限には別の意味があります。内容を読み取ることができずに走査を許可します。ディレクトリ内のファイルを読み取ることができるようにするには、ユーザーはその上のすべてのディレクトリに対する「実行」権限を持っている必要があります。
Webアプリケーションの場合、すべてのファイルにはその所有者による読み取り権限が必要です。それ以外の場合、それはかなり無意味なファイルです。ユーザーと管理者のどちらが(Webアプリケーションを介して)ファイルをアップロードするかにかかわらず、「所有者」(つまり、動的言語)には書き込み権限が必要です。動的言語は大きなファイルを読み込んで内容をエコーするのが遅い傾向があるため、効率的な設定では、Webサーバーを介して静的ファイルを直接提供しようとします。したがって、Webサーバーには静的ファイルへの読み取りアクセス権が必要です。
したがって、最小限のファイル権限は次のとおりです。
一方、最小限のディレクトリ権限は次のとおりです。
ここでも、Webサーバーは、アクセスする必要があるディレクトリより上のすべてのディレクトリに対して「実行」権限を持っている必要があります。そのため、Webサーバーが特定のディレクトリからファイルを提供しない場合でも、実行権限を付与する必要があります。
ほとんどのファイルへの読み取りアクセスをWebサーバーに与えることはかなり一般的です(したがって、それらを500から550に変更してください)。デフォルトの「やや安全な」権限は通常、ディレクトリの場合は755、ファイルの場合は644です。実行権限はなく、誰もが読み取り、ユーザーのみが書き込みできます。Linuxシステム上のファイルの大部分はこれらの権限を持っていることに注意してください。
「その他」の権限は、所有者でもグループでもないシステムユーザー(つまり、残りのすべてのシステムユーザー)を指すことに注意してください。これらのユーザーは不明であるため、「その他」のアクセス許可を制限したままにしておくとよい-明示的にアクセス許可を付与していない。他の権限は、多くの場合、侵害されたシステムで利用するのが最も簡単です(たとえば、/ tmpが一般的なターゲットである理由の1つ)。
上記のコンテキストでは、最後の2つの質問はそれほど関連性がないと思います。ディレクトリのアクセス許可を550(およびファイルのアクセス許可を440)に設定し、アプリケーションが書き込むディレクトリ(たとえば、ディレクトリ:750、ファイル:640)に対する書き込み権限をユーザーに付与します。
(ファイルをアップロードするには書き込み権限が必要であることは明らかですが、必要に応じて後で削除することもできます。ただし、所有者だけが書き込めるディレクトリに誰かが書き込んでいる場合は、おそらくあなたのアカウントが危険にさらされています-これは1つです。制限された権限を維持する理由の)。
通常、ジョブを実行するための最小限の権限セットがあります。ウェブサーバーがあり、ユーザーが共通のグループを共有している場合は、o
へのアクセスを許可する必要をなくすことができます。権限もユーザーに関連しています。 8進数の権限を誤解しているようです。
r-xr-xr-x
ではなくrw-rw-rw
です。それはディレクトリなので、ファイルを作成/削除するには、x
を設定する必要があるので、750 rwxr-x---
を開始するのに適しています。これにより、ディレクトリを所有するユーザーがファイルを追加/削除したり、共通グループの全員がファイルにアクセスしたりできるようになります。一般に、ディレクトリに対してモード0755、0775、または2775を使用します(BSDの場合、およびLinuxの場合、ディレクトリのSGIDビットは、ファイルシステムがBSDセマンティクスでマウントされている場合、新しいファイルのグループの関連付けが親ディレクトリの設定と一致するのではなく、ファイルの作成者のデフォルトGID)。これにより、すべてのユーザーが問題のディレクトリをトラバース(chdirに移動して通過)して読み取る(lsコマンドを実行するか、readdir/readシステムコールを実行する)ことができます。別の方法では、グループ/書き込みオプションを追加します。前述のように、ディレクトリのSGIDビットを使用すると、適切なグループに関連付けられているすべてのファイルとサブディレクトリを保持できます。
ファイルの場合、通常は0644または0664を使用します(誰でも読み取り可能で、グループで書き込み可能かどうか)。明らかにCGIスクリプトとバイナリの場合、xビットを追加する必要があります。また、いくつかの特別な状況では、非常によくテストされたバイナリで、SUIDまたはSGIDビットを追加する場合があります。通常、UNIXおよびLinuxは、スクリプトのSUID/SGIDビットを無視し、ネイティブのコンパイル済み実行可能バイナリのセマンティクスのみを尊重します。ただし、Apacheなどの「setuidhack」などのモジュールを使用してサイトを実行している可能性があります。このモジュールを使用すると、解釈されたスクリプトでもWebサーバーがSUID/SGIDビットを受け入れることができます。 (これは、HTTPデーモンが各ファイルをstat()し、独自のカスタムfork()/ execve()コードを使用して実行ファイルの名前をexecveに直接渡すのではなく、正しいインタープリター文字列をexecve()ベクトルに補間することによって行われます。 ()システムコール)。
これらは、最も一般的なガイドラインにすぎません。これらはすべての状況に「完璧」ではありません。Webサーバー、およびインストールおよび構成しているWebアプリケーションまたはフレームワークのドキュメントを必ず参照してください。おそらく、事前にUNIXセキュリティの専門家に相談する必要があります。ファイル、コード、サーバーを公開インターネットに公開します。