17

Ubuntu Karmic用にパッケージ化されたTomcat 6.0.24を使用しています。Ubuntu の Tomcat パッケージのデフォルトのセキュリティ ポリシーはかなり厳格ですが、単純に見えます。には/var/lib/tomcat6/conf/policy.d、デフォルト ポリシーを確立するさまざまなファイルがあります。

最初に注目する価値があります：

  • ストックTomcatインストールをまったく変更していません-共通のlibディレクトリに新しいjarを入れたり、server.xml変更したりしません.warファイルをwebappsディレクトリに配置することが唯一の展開アクションです。
  • 私が展開しているWebアプリケーションは、このデフォルトポリシーの下で何千ものアクセス拒否で失敗します（-Djava.security.debug="access,stack,failure"システムプロパティのおかげでログに報告されます）。
  • セキュリティ マネージャーを完全にオフにすると、エラーはまったく発生せず、適切なアプリ機能が得られます

私がやりたいのは、アプリケーション固有のセキュリティ ポリシー ファイルをpolicy.dディレクトリに追加することです。これは推奨される方法のようです。これを追加しましたpolicy.d/100myapp.policy（出発点として-最終的には、付与された権限をアプリが実際に必要とするものだけに戻したいと思います）：

grant codeBase "file:${catalina.base}/webapps/ROOT.war" {
  permission java.security.AllPermission;
};

grant codeBase "file:${catalina.base}/webapps/ROOT/-" {
  permission java.security.AllPermission;
};

grant codeBase "file:${catalina.base}/webapps/ROOT/WEB-INF/-" {
  permission java.security.AllPermission;
};

grant codeBase "file:${catalina.base}/webapps/ROOT/WEB-INF/lib/-" {
  permission java.security.AllPermission;
};

grant codeBase "file:${catalina.base}/webapps/ROOT/WEB-INF/classes/-" {
  permission java.security.AllPermission;
};

codeBase正しい宣言を見つけようとする際のスラッシングに注意してください。それはおそらく私の根本的な問題だと思います。

とにかく、上記 (実際には最初の 2 つの付与のみが効果があるように見えます)はほとんど機能します。何千ものアクセス拒否がなくなり、1 つだけが残っています。関連するスタック トレース:

java.security.AccessControlException: access denied (java.io.FilePermission /var/lib/tomcat6/webapps/ROOT/WEB-INF/classes/com/foo/some-file-here.txt read)
  java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
  java.security.AccessController.checkPermission(AccessController.java:546)
  java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
  java.lang.SecurityManager.checkRead(SecurityManager.java:871)
  java.io.File.exists(File.java:731)
  org.apache.naming.resources.FileDirContext.file(FileDirContext.java:785)
  org.apache.naming.resources.FileDirContext.lookup(FileDirContext.java:206)
  org.apache.naming.resources.ProxyDirContext.lookup(ProxyDirContext.java:299)
  org.apache.catalina.loader.WebappClassLoader.findResourceInternal(WebappClassLoader.java:1937)
  org.apache.catalina.loader.WebappClassLoader.findResource(WebappClassLoader.java:973)
  org.apache.catalina.loader.WebappClassLoader.getResource(WebappClassLoader.java:1108)
  java.lang.ClassLoader.getResource(ClassLoader.java:973)

拒否をトリガーしている実際のファイルは無関係であると私は確信しています。これは、オプションの構成パラメーターをチェックするプロパティ ファイルです。興味深いのは、次のことです。

  1. このコンテキストには存在しません
  2. ファイルが存在しないという事実は、単に false を返すのではなく、セキュリティ例外をスローすることになりますjava.io.File.exists()(ただし、これは読み取り許可のセマンティクスの問題だと思います)。

別の回避策 (Tomcat でセキュリティ マネージャーを無効にする以外に) は、ポリシー ファイルに無制限のアクセス許可を追加することです。

grant {
  permission java.security.AllPermission;
};

これは、セキュリティ マネージャをオフにすることと機能的に同等であると思います。

助成金の宣言が微妙に間違っているに違いないと思いますがcodeBase、現時点ではそれを見ていません。

4

4 に答える 4

2

Ubuntu のパッケージ管理バージョンを使用していますか? 最近、セキュリティに関する悪夢に見舞われましたが、Tomcat を個別にダウンロードして使用することで、セキュリティの問題が解消されることがわかりました。

確証:

http://www.howtogeek.com/howto/linux/installing-tomcat-6-on-ubuntu/

Ubuntu を実行していて、Tomcat サーブレット コンテナーを使用する場合は、正しく動作しないため、リポジトリのバージョンを使用しないでください。代わりに、ここで概説している手動のインストール プロセスを使用する必要があります。

于 2010-04-29T09:53:14.230 に答える
0

Tomcatは独自のtomcatユーザーで実行されます。戦争ファイルはそのユーザーに見える必要があります-おそらく最初にそれをチェックする価値がありますか？

于 2010-04-16T02:09:51.780 に答える
0

ROOT ディレクトリに直接デプロイしていますか?

通常、戦争を webapps フォルダーに入れると、たとえば100myapp.war、それ自体という名前のフォルダーに解凍され100myappます。ROOT フォルダーではなく、この新しいフォルダーに対して許可を行うべきではありませんか?

于 2010-04-22T05:02:06.710 に答える
0

ファイル アクセス許可を個別に付与する必要がある可能性があります。アプリの許可を次のように変更してみてください。

grant codeBase "file:${catalina.base}/webapps/ROOT.war" {
  permission java.security.AllPermission;
  permission java.io.FilePermission "file:${catalina.base}/webapps/ROOT/-", "read, write";
}

それがうまくいかない場合は、既存の許可がカバーする範囲外のコードがそれらのプロパティ ファイルにアクセスしている可能性があります (サーブレットや他のライブラリ コードなど)。

回避策として、これが事実であるかどうかを確認するために、問題の原因となっている .properties に対してストレート許可を行うことができます。

grant {
  permission java.io.FilePermission "file:${catalina.base}/webapps/ROOT/WEB-INF/classes/com/foo/some-file-here.txt", "read, write";
}

スタック トレースが Tomcat のコンテキスト ローダーのコードを示しているため、実際には後者の可能性があるようです。.properties に対する単純な許可が機能する場合は、許可を org.apache.naming.resources.FileDirContext にロックダウンすることをお勧めします。

独自のコードに固有のスタック トレースを取得していますか?

于 2010-04-22T12:34:39.093 に答える