JAvaセキュリティ権限ポリシー
7906 ワード
JAvaは多くの企業で広く応用される言語となり、完備、強大な機能のほか、重要なのはその安全性である.javaはプログラムの作成、コンパイル、クラスのロードプロセス、実行の各ステップから安全検査を行うように設計されている.ここでjavaの安全管理器とアクセス権限「安全管理器はある操作が実行できるかどうかを制御するクラスである.」
セキュリティマネージャがチェックする操作には、次のものが含まれます. 新しいクラスローダ を作成する 仮想マシンを終了します. 反射を使用して別のクラスのメンバーにアクセスします. ローカルファイルにアクセスします. ソケット接続を開きます. 印刷ジョブを開始します. システムクリップボードにアクセスします. AWTタイムキューにアクセスします. 最上階のウィンドウを開きます. Javaクラスライブラリ全体に類似のチェックがたくさんあります.
javaアプリケーションを実行する場合、デフォルトの設定はセキュリティマネージャをインストールしないので、すべての操作が許可されます.一方、appletブラウザは機能が制限されたセキュリティポリシーを実行します.
そのセキュリティポリシーは、コードソースとアクセス権セットとのマッピング関係を構築します.
ファイルアクセスの例
セキュリティポリシーファイル
ポリシー・クラスでは、コード・ソースを権限にマッピングするコマンドを含む応答のセキュリティ・ポリシー・ファイルを読み込む必要があります.jdkでは、デフォルトで2つの場所でセキュリティ・サイド・ファイルをインストールできます.
JAvaプラットフォームホームのjava.policyファイル ユーザーホームの.java.policyファイル(ファイル名の前のドットに注意) 注意:java.securityプロファイルでこれらのファイルの位置を変更できます.デフォルトの位置は
policy.url.1=file:${java.home}/lib/security/java.policy
policy.url.2=file:${user.home}/.java.policy
もう1つの態様は、各アプリケーションに表示するポリシーファイルを構成することである.
(ポリシーファイル形式参照公式ドキュメント)
ポリシー・ファイルを有効にするには、アプリケーションのmainメソッドの内部でシステム・プロパティを設定する2つの方法があります.
1.
2.仮想マシンコマンドライン起動パラメータ
Appletの場合
これらの例では、app.policyファイルが他の有効なポリシーに追加されます.コマンドラインに2番目の等号が追加された場合、次のようになります.
アプリケーションは指定されたポリシーファイルを使用するだけで、標準的なポリシーファイルは無視されます.
前述したように、デフォルトjavaはセキュリティマネージャをインストールしません.そのため、セキュリティマネージャをインストールする前にポリシーファイルの役割が見えません.セキュリティマネージャを有効にするには、mainメソッドに追加できます.
または、仮想マシンの起動時にコマンドラインオプション-Djava.security.managerを追加します.
ファイルに対するfile permissionへのアクセス
JAva.io.FilePermissionにはread,write,execute,deleteの4つの操作がありますもう1つの注意点は: コードは、明示的な認可を必要とせずに、常に自分のディレクトリ(またはそのディレクトリのサブディレクトリ)内のファイルを読み取ることができます.(since JDK API 1.2)つまり、デフォルトではコードは常に自分のディレクトリのファイルに読み取り可能な権限を持っているが、他のwrite、execute、deleteの権限はない.
「各クラスには、クラスをカプセル化するためのコードソースとパーミッションのセットのオブジェクトである保護ドメインがあります.SecurityManagerクラスが、現在呼び出しスタック上にあるすべてのメソッドを確認するクラスをチェックし、すべてのクラスの保護ドメインを取得し、現在チェックされている操作を実行できるかどうかを各保護欲に尋ねる必要があります.のドメインはすべて同意して、それでは検査は合格します.さもなくば、1つのSecurityManagerの異常を投げ出します."
ここで私とパートナーのテスト方法は、アプリケーションディレクトリの前のディレクトリの1つのディレクトリの権限をテストすることです.ポリシーファイルとアプリケーションファイルは同じディレクトリにあります. PermissionTest.policy
なお、user.dirというpropertyの読み取り権限は、上位ディレクトリで使用するjava.io.Fileのメソッドをアプリケーションで取得する必要があるが、実行中にエラーが発生し、user.dirは読めないため、Fileのメソッドがuser.dirというpropertyに使用されているはずなので、ここでもこの権限を加算. 応答するjava.util.PropertyPermission権限はjavaディレクトリのjava.policyファイルの応答内容を参照することができ、user.dir属性の目標がないことに注意する.同時に、テストプログラム自体のディレクトリのファイルをテストした.テストプログラム PermissionTest.java
実行権限をチェックするcheckExecメソッドについても説明します.JDK APIを参照してください.
public void checkExec(String cmd)
……
cmdが絶対パスである場合、このメソッドはFilePermission(cmd,「execute」)権限を使用してcheckPermissionを呼び出し、そうでない場合はFilePermission(「<>」、「execute」)権限を使用してcheckPermissionを呼び出します.
……
したがって、checkExecは絶対パスファイルを使用して呼び出す必要があります.もちろん、checkPermission(Permission p)でチェックすることができます.これにより、絶対パスの問題は発生しません.コマンドラインはテストを実行します.
ポリシーファイルおよびテストプログラムを変更すると、異なる権限の変化が見られる.
--参考資料『JAVAコアテクノロジー(Core Java)』原書第8版
セキュリティマネージャがチェックする操作には、次のものが含まれます.
javaアプリケーションを実行する場合、デフォルトの設定はセキュリティマネージャをインストールしないので、すべての操作が許可されます.一方、appletブラウザは機能が制限されたセキュリティポリシーを実行します.
そのセキュリティポリシーは、コードソースとアクセス権セットとのマッピング関係を構築します.
ファイルアクセスの例
セキュリティポリシーファイル
ポリシー・クラスでは、コード・ソースを権限にマッピングするコマンドを含む応答のセキュリティ・ポリシー・ファイルを読み込む必要があります.jdkでは、デフォルトで2つの場所でセキュリティ・サイド・ファイルをインストールできます.
JAvaプラットフォームホームのjava.policyファイル ユーザーホームの.java.policyファイル(ファイル名の前のドットに注意) 注意:java.securityプロファイルでこれらのファイルの位置を変更できます.デフォルトの位置は
policy.url.1=file:${java.home}/lib/security/java.policy
policy.url.2=file:${user.home}/.java.policy
もう1つの態様は、各アプリケーションに表示するポリシーファイルを構成することである.
(ポリシーファイル形式参照公式ドキュメント)
ポリシー・ファイルを有効にするには、アプリケーションのmainメソッドの内部でシステム・プロパティを設定する2つの方法があります.
1.
System.setProperty("java.security.policy", "app.policy");
2.仮想マシンコマンドライン起動パラメータ
java -Djava.security.policy=app.policy App
Appletの場合
applietviewer -J-Djava.security.policy=app.policy applet.html
これらの例では、app.policyファイルが他の有効なポリシーに追加されます.コマンドラインに2番目の等号が追加された場合、次のようになります.
java -Djava.security.policy==app.policy App
アプリケーションは指定されたポリシーファイルを使用するだけで、標準的なポリシーファイルは無視されます.
前述したように、デフォルトjavaはセキュリティマネージャをインストールしません.そのため、セキュリティマネージャをインストールする前にポリシーファイルの役割が見えません.セキュリティマネージャを有効にするには、mainメソッドに追加できます.
System.setSecurityManager(new SecurityManager());
または、仮想マシンの起動時にコマンドラインオプション-Djava.security.managerを追加します.
java -Djava.security.manager -Djava.security.policy=app.policy App
ファイルに対するfile permissionへのアクセス
JAva.io.FilePermissionにはread,write,execute,deleteの4つの操作がありますもう1つの注意点は: コードは、明示的な認可を必要とせずに、常に自分のディレクトリ(またはそのディレクトリのサブディレクトリ)内のファイルを読み取ることができます.(since JDK API 1.2)つまり、デフォルトではコードは常に自分のディレクトリのファイルに読み取り可能な権限を持っているが、他のwrite、execute、deleteの権限はない.
「各クラスには、クラスをカプセル化するためのコードソースとパーミッションのセットのオブジェクトである保護ドメインがあります.SecurityManagerクラスが、現在呼び出しスタック上にあるすべてのメソッドを確認するクラスをチェックし、すべてのクラスの保護ドメインを取得し、現在チェックされている操作を実行できるかどうかを各保護欲に尋ねる必要があります.のドメインはすべて同意して、それでは検査は合格します.さもなくば、1つのSecurityManagerの異常を投げ出します."
ここで私とパートナーのテスト方法は、アプリケーションディレクトリの前のディレクトリの1つのディレクトリの権限をテストすることです.ポリシーファイルとアプリケーションファイルは同じディレクトリにあります. PermissionTest.policy
grant {
permission java.util.PropertyPermission "user.dir", "read";
permission java.io.FilePermission "../test", "write";
};
なお、user.dirというpropertyの読み取り権限は、上位ディレクトリで使用するjava.io.Fileのメソッドをアプリケーションで取得する必要があるが、実行中にエラーが発生し、user.dirは読めないため、Fileのメソッドがuser.dirというpropertyに使用されているはずなので、ここでもこの権限を加算. 応答するjava.util.PropertyPermission権限はjavaディレクトリのjava.policyファイルの応答内容を参照することができ、user.dir属性の目標がないことに注意する.同時に、テストプログラム自体のディレクトリのファイルをテストした.テストプログラム PermissionTest.java
import java.io.FilePermission;
import java.io.File;
public class PermissionTest {
public static void main(String[] args) {
SecurityManager manager = System.getSecurityManager();
File f = new File("");
System.out.println(System.getProperty("user.dir"));
System.out.println(f.getAbsoluteFile().getParent());
try{
manager.checkRead("../test");
System.out.println(" !");
} catch (SecurityException e) {
System.out.println(" !");
System.out.println(e.getMessage());
}
try{
manager.checkWrite("../test");
System.out.println(" !");
} catch (SecurityException e) {
System.out.println(" !");
System.out.println(e.getMessage());
}
try{
manager.checkDelete("../test");
System.out.println(" !");
} catch (SecurityException e) {
System.out.println(" !");
System.out.println(e.getMessage());
}
try{
manager.checkExec(f.getAbsoluteFile().getParent() + File.separator + "test");
System.out.println(" !");
} catch (SecurityException e) {
System.out.println(" !");
System.out.println(e.getMessage());
}
System.out.println("======= =======");
try{
manager.checkRead("TEM");
System.out.println("TEM !");
} catch (SecurityException e) {
System.out.println("TEM !");
System.out.println(e.getMessage());
}
try{
manager.checkWrite("TEM");
System.out.println("TEM !");
} catch (SecurityException e) {
System.out.println("TEM !");
System.out.println(e.getMessage());
}
try{
manager.checkDelete("TEM");
System.out.println("TEM !");
} catch (SecurityException e) {
System.out.println("TEM !");
System.out.println(e.getMessage());
}
try{
manager.checkExec(System.getProperty("user.dir") + File.separator + "TEM");
System.out.println("TEM !");
} catch (SecurityException e) {
System.out.println("TEM !");
System.out.println(e.getMessage());
}
System.out.println("Fine.");
}
}
実行権限をチェックするcheckExecメソッドについても説明します.JDK APIを参照してください.
public void checkExec(String cmd)
……
cmdが絶対パスである場合、このメソッドはFilePermission(cmd,「execute」)権限を使用してcheckPermissionを呼び出し、そうでない場合はFilePermission(「<
……
したがって、checkExecは絶対パスファイルを使用して呼び出す必要があります.もちろん、checkPermission(Permission p)でチェックすることができます.これにより、絶対パスの問題は発生しません.コマンドラインはテストを実行します.
java -Djava.security.manager -Djava.security.policy==PermissionTest.policy PermissionTest
ポリシーファイルおよびテストプログラムを変更すると、異なる権限の変化が見られる.
--参考資料『JAVAコアテクノロジー(Core Java)』原書第8版