Tomcatを安全にするセキュリティマネージャとは？：Tomcatはどこまで“安全”にできるのか？（6）（2/3 ページ）

セキュリティマネージャの効果を確認

　Tomcatの再起動が完了したら、セキュリティマネージャの効果を確認してみましょう。先ほどのTomcatを停止させてしまう危険なJSPにアクセスしてみましょう。

図2　Tomcatによるエラー画面が表示された

　どうですか？ Tomcatは無事に停止せずにエラー画面が表示されました。セキュリティマネージャのパーミッションクラス（パッケージへのアクセス権限を管理／許可するためのクラス）「java.lang.RuntimePermission」で定義可能な「exitVM」の設定により、「System.exit(0)」のコードを実行した際にJava VMを停止させることを禁止できました。

　これで、無事にセキュリティマネージャが有効になっていることが確認できました。

Tomcatのセキュリティポリシーとは？

　セキュリティマネージャを初期状態のまま起動してみましたが、このままで本当にいいのでしょうか？ いいえ。このままでは過去に作成したアプリケーション群に影響が出る可能性があります。

Cometチャットでセキュリティマネージャを試す

　試しに、連載第3回「Tomcat 6で実現！ Ajaxを超える通信技術Comet」で作成したCometを利用したチャット・アプリケーションを開いてみると……。

図3　Cometチャットを起動したらエラーが……

　見たことのないエラーが発生してしまいました。これでは、せっかく作成したCometチャットが利用できません。ログファイルを見てみると、こんなエラーが表示されていました。

2008/04/03 20:57:15 org.apache.catalina.core.ApplicationContext log
情報: サーブレット CometServlet を利用不可能にマークします
2008/04/03 20:57:15 org.apache.catalina.core.ApplicationContext log
致命的: Error loading WebappClassLoader
 delegate: false
 repositories:
 /WEB-INF/classes/
 ----------> Parent Classloader:
 org.apache.catalina.loader.StandardClassLoader@14ed9ff
 CometServlet
 java.lang.ClassNotFoundException: CometServlet
 at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1360)
 
……（省略）……
 
at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:719)
 
……（省略）……
 
at java.lang.Thread.run(Thread.java:595)
 2008/04/03 20:57:15 org.apache.catalina.core.StandardWrapperValve invoke
 致命的: サーブレット CometServlet に例外を割り当てます
 java.lang.ClassNotFoundException: CometServlet
 at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1360)
 
……（省略）……
 
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:719)
 at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2080)
 at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
 at java.lang.Thread.run(Thread.java:595)

　Webアプリケーション「CometServlet」のクラスローダが読み込めないようです。試しに再度アクセスしてみると、エラーの内容が変わってしまいました。

図4　変わってしまったエラー内容

　ログファイルを見ると、やはりサーブレットが利用できないと書かれています。

2008/04/03 20:58:35 org.apache.catalina.core.StandardWrapperValve invoke
情報: サーブレット CometServlet は現在利用できません

　一体、なぜなのでしょうか？

Cometチャットが動かなかったワケ

　Tomcat上でセキュリティマネージャを利用する場合、Tomcatのクラスローダによってロードされたクラスに対して厳密にクラスへのアクセス許可を設定していく必要があります。セキュリティマネージャを利用する場合には、環境に合わせてセキュリティポリシーを定義しておかなければなりません。

　今回のCometチャットでは、初期状態のセキュリティポリシーで利用が制限されてしまう状態だったのでしょう。

Tomcatのセキュリティポリシーの中身

　このTomcatのセキュリティポリシーは「catalina.policy」というファイル名でTomcatのインストールされたディレクトリ内の「conf」ディレクトリに格納されています（本連載では、「/opt/tomcat6/conf」以下）。

　このセキュリティポリシーが書かれているファイルは初期状態で3つのセクションが定義されており、それぞれは以下のようになっています。

1. SYSTEM CODE PERMISSIONS
   Javaを実行するために定義されたポリシー
2. CATALINA CODE PERMISSIONS
   TomcatのAPIを利用するために定義されたポリシー
3. WEB APPLICATION PERMISSIONS
   発行したWebアプリケーションを制御するためのポリシー

　さて、それでは実際にどのようにしてパーミッションが定義されているかを見ていきましょう。ここでの記述フォーマットは以下のようになっています。

grant codeBase "file:${java.home}/lib/-" {      ……（1）
    permission java.security.AllPermission;     ……（2）
}; 

　（1）はセキュリティポリシーの“宣言”部分に当たります。「codeBase」とは、指定したコードの格納されている場所を指定します。codeBaseの指定がない場合、すべてのコードに対して設定を行います。

　（2）はパーミッションのエントリを定義します。対象に指定したコードにパーミッションクラスの許可設定を行います。「許可するパーミッションクラス 対象,動作」というフォーマットで定義します。

　上記は（1）で定義したコード（クラス）が（2）のパーミッションクラスに対する動作を定義していることになります。この例の場合、「${java.home}/lib/」つまり、Javaのホームディレクトリ以下にある「lib」ディレクトリ内のファイルはすべてのクラスへのアクセスを許可するという設定です。

　次ページでは、Tomcatへ適用可能なさまざまなパーミッションクラスを紹介し、セキュリティポリシーにセキュリティマネージャを設定する方法を解説します。