5

Ubuntu の Tomcat で実行される Web アプリケーションを作成しています。Ubuntu では、Tomcat はデフォルトで Java SecurityManager で実行するように構成されています。私自身の Web アプリケーション以外には、BIRT レポート エンジンなど、私自身に関連する有名なサード パーティの Web アプリケーションのみが存在します。

Web アプリケーションの 1 つに障害が発生したり、侵害されたりした場合、他のすべてのアプリケーションが損傷を受けることなくダウンする可能性があります。私が起こりたくないことは、侵害されたWebアプリがシステム自体を侵害することです。たとえば、 rm -r / を呼び出します

これを実現するには、Java セキュリティ マネージャを使用する必要がありますか? それとも、1 つの Web アプリを他のアプリから保護するだけでよいのでしょうか? 使用する予定のすべてのサード パーティ Web アプリケーションに対して .policy ファイルを作成する作業を防止したいと考えています。

4

3 に答える 3

3

理論的にはそうです。しかし、セキュリティ マネージャを使用してサーバー側のコードを "ロックダウン" しようとすると、問題が山積みになっていると聞いたことがあります。多くの場合、アプリケーションはこれを念頭に置いて設計されておらず、すべてのアクセス許可の設定が正しくなるまで、SecurityExceptions のデバッグに多くの時間を費やします。

編集：

2 つの Tomcat インスタンスを実行して、1 つのアプリケーションが 1 つの Tomcat ですべてをダウンさせるようなことを行うという問題を回避する方が簡単であることをお勧めします。(たとえば、ヒープをいっぱいにする、ファイル記述子をリークする、または System.exit() を呼び出す)。

アプリケーションが Java から「抜け出し」、「rm /*」と同等の処理を行うことをまだ懸念している場合は、各 Tomcat インスタンスを個別の「chroot jail」または仮想ホストで実行できます。または、Tomcat を制限されたユーザー アカウントから実行し、そのアカウントが許可されていないファイルにアクセス/更新できないようにすることもできます。

于 2009-08-14T11:28:57.010 に答える
1

SecurityManager は、Tomcat に適用できるもう 1 つのセキュリティ レイヤーにすぎません。アプリケーションによっては、正しく設定するのが非常に難しく、時間がかかる場合があります。既に述べたように、サードパーティのアプリケーションやライブラリでこれを正しく行うことは、さらに困難になる可能性があります。

私の意見では、これを詳細に構成することは、考慮すべき最後のことです。

これの多くはすでにここで述べられていますが、私があなただったら、次の手順を順番に実行します。

  1. 最小限の特権を持つアカウント (慣例により、'tomcat'、'tomcat6' などの名前のアカウント) で jsvc を使用して Tomcat を実行します。Ubuntu パッケージをインストールした場合、インストールされた init スクリプトは既にこれを行っているため、このスクリプトを介して tomcat を起動すれば問題ありません。jsvc の詳細については、http: //tomcat.apache.org/tomcat-6.0-doc/setup.html を参照してください。
  2. chroot を使用して jsvc を実行します。chroot で指定する仮想ファイルシステムの内容を、Tomcat が必要とするものだけに制限します。
  3. Tomcat、データベース、および OS 構成を保護します。Center for Information Security には、これに関する適切なベースライン ガイダンスがあります - http://cisecurity.org/en-us/?route=downloads.multiform。
  4. アプリケーションのセキュリティ。これは最も重要ですが、1.、2.、および 3. は比較することで非常に簡単に達成できるため、この前に (または並行して) 実行することをお勧めします。アプリケーションへのすべての入力は、使用前に必ず検証してください。OWASP の Enterprise Security API のようなものを出発点として使用します - http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API。それ以外のことはすべて、アプリケーションのセキュリティ対策のフェイルセーフです。アプリケーションが安全でない場合、他の手順 (権限の低いアカウント、chroot、安全な構成など) を行っているため、アプリケーションが実行されているマシンは安全なままである可​​能性がありますが、アプリケーションが管理するデータは危険にさらされます。
  5. 保安管理者。アプリケーション セキュリティの適切なベースラインが得られたことに満足したら、ぜひ、進行中のアプリケーション セキュリティの取り組みにセキュリティ ポリシーを追加することを検討してください。

他にできることには、マシン上で Snort のような IDS を実行して侵入の試みを検出すること、swatch のようなファイル ウォッチャーを実行して予期しないファイルの変更 (特に構成ファイルへの変更) を検出すること、さまざまなログ アナライザーを実行して他の侵入の試みを検出することなどがあります。 .

セキュリティの取り組みには常にトレードオフがあります。アプリケーションを完全に保護することはできません。ほとんどの人にとって、本格的なセキュリティ マネージャの構成は、このカテゴリに分類されます。

「これを実現するために Java セキュリティ マネージャを使用する必要がありますか? [システム自体を危険にさらす]?」

いいえ。もっと簡単な方法があります (低特権アカウント、chroot、安全な構成など)。

于 2010-04-22T13:29:59.563 に答える
1

" " を回避するrm -r /ために、セキュリティ マネージャーは必要ありません。/Tomcat プロセスを実行するユーザーのアクセスが制限されていれば十分です (つまり、他の重要な領域への書き込みアクセス権がありません)。

于 2009-08-14T11:36:41.597 に答える