Javaセキュリティの進化と概念、パート3:アプレットのセキュリティ

Javaの初期の成長は、アプレットとしてよく知られているネットワーク経由でダウンロード可能なコードによって促進されましたアプレットのセキュリティはJavaの成長とともに進化してきましたが、今日では、Javaのバージョン、市販のブラウザ、プラグインが多様であるため、混乱が頻繁に発生しています。

シリーズの第3回目となるこの記事では、ネットワークからダウンロードしたJavaコードを安全に実行するためのさまざまな要件について説明します。モバイルコードは革新的な概念ではありませんが、Javaとインターネットはコンピュータのセキュリティにいくつかの固有の課題を提示します。Javaアーキテクチャの進化とコアJavaセキュリティへの影響については、パート1とパート2で説明しました。この記事では、ローカルファイルシステムに書き込む単純なアプレットをデプロイすることで、すべての概念を結び付ける実践的なアプローチを採用しています。 。

Javaセキュリティの進化と概念:シリーズ全体を読んでください!

  • パート1:この入門概要でコンピューターセキュリティの概念と用語を学ぶ
  • パート2:Javaセキュリティの詳細を発見する
  • パート3:自信を持ってJavaアプレットのセキュリティに取り組む
  • パート4:オプションパッケージがJavaセキュリティを拡張および強化する方法を学ぶ
  • パート5:J2SE 1.4は、Javaセキュリティに多くの改善を提供します

この例では、アプレットのコアは、このシリーズの前半で紹介した公開鍵暗号です。署名者の秘密鍵を使用して署名されたコードは、署名者に対応する公開鍵がそれぞれのマシンで信頼されていると見なされると、クライアントマシンで実行できます。また、アクセス許可とキーストアを一致させるポリシーファイルを公開鍵と秘密鍵のリポジトリとして使用する方法についても説明します。さらに、Java 2 SDKセキュリティツールとNetscapesigntoolは、展開を可能にするため、それらに焦点を当てます。

この記事では、Java 2の初期リリースのアプリケーションセキュリティから始まり、最新バージョンのJava 2、バージョン1.3に移行するJavaセキュリティの進化をたどります。このアプローチは、非常に単純な概念から始めて、かなり高度な例で終わるまで、概念を徐々に導入するのに役立ちます。

このシリーズは、コンピュータセキュリティの包括的なガイドを提供することを目的としていません。コンピュータのセキュリティは、いくつかの分野、部門、文化に影響を与える多面的な問題です。テクノロジーへの投資は、人材育成への投資、ポリシーの厳格な実施、および全体的なセキュリティポリシーの定期的なレビューでフォローアップする必要があります。

注:この記事では、アプレットのセキュリティ問題を示すために設計された、実行中のJavaアプレットについて説明します。詳細については、以下をお読みください。

アプリケーションのセキュリティ

アプリケーションのセキュリティを見て、調査を始めましょう。パート2では、Javaセキュリティがサンドボックスモデルからきめ細かいセキュリティモデルにどのように進化したかを見ました。また、アプリケーション(ローカルコード)はデフォルトで自由に管理され、通常は信頼できないと見なされるアプレット(ネットワークでダウンロード可能なコード)と同じ制御の対象にならないこともわかりました。過去からの変更点として、Java 2では、セキュリティアプリケーションはオプションでアプレットと同じレベルの制御を受けることができます。

まず、writeFile.javaJava 2のセキュリティ機能を説明するためにこの記事で使用されているコードについて簡単に説明します。このプログラムは、Sunが提供するアプレットコードを少し変更したもので、Java2の機能の一部を説明するためにWebから入手できます。セキュリティ。プログラムは、アプリケーションサポートを提供するように変更され、ローカルファイルシステムでファイルを作成および書き込みしようとします。ローカルファイルシステムへのアクセスは、セキュリティマネージャによってスクリーニングされます。この記事全体を通して、この特定の操作を安全な方法で許可する方法を説明します。

/ ** *デフォルトでは、これによりアプレットとしてセキュリティ例外が発生します。 * * JDK 1.2 appletviewerで、*「Duke」によって署名されたアプレットを許可するようにシステムを構成し、JavaソフトウェアWebサイトからダウンロードして、ファイルを/ tmpディレクトリ(または「C:\ tmpfoo」という名前のファイル)に書き込む場合"* Windowsシステムの場合)、このアプレットを実行できます。 * * @version JDK 1.2 * @author Marianne Mueller * @Modified by Raghavan Srinivas [Rags] * / importjava.awt。*;インポートjava.io. *;インポートjava.lang。*; importjava.applet。*; public class writeFile extends Applet {String myFile = "/ tmp / foo";ファイルf = new File(myFile); DataOutputStream dos; public void init(){String osname = System.getProperty( "os.name"); if(osname.indexOf( "Windows")!= -1){myFile = "C:" + File.separator + "tmpfoo";}} public void paint(Graphics g){try {dos = new DataOutputStream(new BufferedOutputStream(new FileOutputStream(myFile)、128)); dos.writeBytes( "猫はあなたが最も期待しないときに催眠術をかけることができます\ n"); dos.flush(); dos.close(); g.drawString( "" + myFile + "という名前のファイルへの書き込みに成功しました-見てください!"、10、10); } catch(SecurityException e){g.drawString( "writeFile:キャッチされたセキュリティ例外"、10、10); } catch(IOException ioe){g.drawString( "writeFile:キャッチされたI / O例外"、10、10); }} public static void main(String args []){Frame f = new Frame( "writeFile"); writeFile writefile = new writeFile(); writefile.init(); writefile.start(); f.add( "Center"、writefile); f.setSize(300、100); f.show(); }}}}}}猫はあなたが最も期待しないときに催眠術をかけることができます\ n "); dos.flush(); dos.close(); g.drawString(" "+ myFile +"という名前のファイルに正常に書き込まれました-見てください! "、10、10);} catch(SecurityException e){g.drawString(" writeFile:catched security exception "、10、10);} catch(IOException ioe){g.drawString(" writeFile:catched i / o例外 "、10、10);}} public static void main(String args []){Frame f = new Frame(" writeFile "); writeFile writefile = new writeFile(); writefile.init(); writefile.start( ); f.add( "Center"、writefile); f.setSize(300、100); f.show();}}猫はあなたが最も期待しないときに催眠術をかけることができます\ n "); dos.flush(); dos.close(); g.drawString(" "+ myFile +"という名前のファイルに正常に書き込まれました-見てください! "、10、10);} catch(SecurityException e){g.drawString(" writeFile:catched security exception "、10、10);} catch(IOException ioe){g.drawString(" writeFile:catched i / o例外 "、10、10);}} public static void main(String args []){Frame f = new Frame(" writeFile "); writeFile writefile = new writeFile(); writefile.init(); writefile.start( ); f.add( "Center"、writefile); f.setSize(300、100); f.show();}}} catch(SecurityException e){g.drawString( "writeFile:キャッチされたセキュリティ例外"、10、10); } catch(IOException ioe){g.drawString( "writeFile:キャッチされたI / O例外"、10、10); }} public static void main(String args []){Frame f = new Frame( "writeFile"); writeFile writefile = new writeFile(); writefile.init(); writefile.start(); f.add( "Center"、writefile); f.setSize(300、100); f.show(); }}} catch(SecurityException e){g.drawString( "writeFile:キャッチされたセキュリティ例外"、10、10); } catch(IOException ioe){g.drawString( "writeFile:キャッチされたI / O例外"、10、10); }} public static void main(String args []){Frame f = new Frame( "writeFile"); writeFile writefile = new writeFile(); writefile.init(); writefile.start(); f.add( "Center"、writefile); f.setSize(300、100); f.show(); }}

Java 2 Runtime Environment、Standard Edition(JRE)で生成されたバイトコードを実行すると、デフォルトのポリシーではJava 2アプリケーションがセキュリティマネージャの対象にならないため、アプリケーションはデフォルトでローカルファイルシステム上のファイルを変更できます。アプリケーションは通常、ローカルで生成されたコードであり、ネットワーク経由でダウンロードされないため、このポリシーは正当化されます。次のコマンドラインは、ファイルが作成されて書き込まれたことを示す、図1に示すウィンドウを生成します。

$ java writeFile 

コードをJava2セキュリティマネージャに適用するには、次のコマンドラインを呼び出します。これにより、図2に示す結果が生成されます。アプリケーションがローカルファイルシステムを変更しようとしたためにセキュリティ例外が生成されたことに注意してください。明示的に含まれているセキュリティマネージャが例外を生成しました。

$ java -Djava.security.manager writeFile 

上に示したケースは、セキュリティポリシーの極端な例を表しています。前者の場合、アプリケーションは制御の対象ではありませんでした。後者では、それは非常に厳格な管理の対象となりました。ほとんどの場合、その間のどこかにポリシーを設定する必要があります。

ポリシーファイルを使用して、中間ポリシーを実行できます。これを行うにall.policyは、作業ディレクトリで呼び出されるポリシーファイルを作成します。

付与{パーミッションjava.io.FilePermission "<>"、 "write"; };

次のコマンドラインで同じコードを実行すると、ローカルファイルシステムを変更できます。

$ java -Djava.security.manager -Djava.security.policy = all.policy writeFile 

この例では、アプリケーションはセキュリティマネージャの対象でしたが、全体的なポリシーはポリシーファイルによって管理されていたため、ローカルファイルシステム上のすべてのファイルを変更できました。より厳密なポリシーは、関連するファイルtmpfoo(この場合)のみの変更を許可することであった可能性があります。

エントリの構文など、ポリシーファイルの詳細については、この記事の後半で説明します。しかし、最初に、アプレットのセキュリティを見て、アプリケーションのセキュリティと対比してみましょう。

アプレットのセキュリティ

これまで、アプリケーションのセキュリティについて研究してきました。そのため、ほとんどのセキュリティ機能には、コマンドラインからアクセスして変更できます。アプレット環境で十分に安全でありながらある程度柔軟なポリシーを提供することは、かなり困難であることがわかります。まず、でのアプレットの展開について見ていきますAppletviewer。ブラウザでデプロイされたアプレットについては後で説明します。

Javaコードポリシーは、主にによって決定されますCodeSource。これは、コードの発信元と署名者の2つの情報で構成されます。

Appletviewer

writeFile.html次の内容で呼び出されるファイルを作成します。

  Javaセキュリティの例:ファイルの書き込み 
   

Running the applet with the following command line would result in the window shown in Figure 3:

$ appletviewer writeFile.html 

Notice that -- in contrast to what would happen with an application -- the applet generated an exception since the applet is subject to the security manager by default. The installation can be governed by a customizable policy, if required. Running the following command line:

appletviewer -J"-Djava.security.policy=all.policy" writeFile.html 

would, as you might expect, allow modification of the tmpfoo file, since this was permitted in accordance with the policy file.

Browsers

Applet security in browsers strives to prevent untrusted applets from performing potentially dangerous operations, while simultaneously allowing optimal access to trusted applets. Applet security deployment in browsers is substantially different from what we have seen so far, primarily due to the following reasons:

  • A default lack of trust in code downloaded over the network
  • Insufficient access to the command-line options for running the JVM, since the JVM is hosted in the context of a browser
  • Inadequate support for some of the latest security features in the JVMs bundled with browsers

As for the first problem, to obviate the potential problems resulting from running untrusted code, earlier versions of Java used the sandbox model (see "Sidebar 1: Sandbox Model"). Trust is a largely philosophical or emotional issue, rather than a technical issue; however, technology can help. For example, Java code can be signed using certificates. In this example, the signer implicitly vouches for the code by signing it. The onus is ultimately upon the user running the code to trust the signing entity or not, given that these certificates guarantee that the code was indeed signed by the intended person or organization.

The second problem stems from the lack of access to the options for running the JVM in the browser context. For example, there is no simple way to deploy and use customized policy files as we could in the previous example. Instead, such policies will have to be set by files based on the JRE installation. Customized class loaders or security managers cannot be installed easily.

The third problem, the lack of support for the latest versions of the JRE in the default JVM with the browser, is solved by using the Java plug-in (see "Sidebar 2: Java Plug-in Primer"). Indeed, an underlying issue is that modification of policy files is not very straightforward. Since applets may be deployed on thousands or even millions of client machines, there might be environments where users might not have a good understanding of security or may not be acquainted with methods for modifying the policy file. The Java plug-in provides a workaround, although it's recommended to use policy files wherever practical and applicable.

Next, we'll look in more detail at applet security involving code-signing examples in a browser environment with a Java plug-in. We will confine the discussion to Java plug-in version 1.3 unless explicitly stated otherwise.

The Java plug-in and security

The Java plug-in supports the standard Java 2 SDK, Standard Edition (J2SE), including the security model. All applets run under the standard applet security manager, which prevents potentially malicious applets from performing dangerous operations, such as reading local files. RSA-signed applets can be deployed using the Java plug-in. Additionally, the Java plug-in attempts to run applets in an identical way in both Netscape Navigator and Internet Explorer by avoiding browser-specific resources. This ensures that an RSA-signed applet will run identically in both browsers with the Java plug-in. The Java plug-in also supports HTTPS, a secure version of HTTP.

In order for a plug-in-enhanced browser to trust an applet and grant it all privileges or a set of fine-grained permissions (as specified in a J2EE policy file), the user has to preconfigure his or her cache of trusted signer certificates (the .keystore file in JRE 1.3) to add the applet's signer to it. However, this solution does not scale well if the applet needs to be deployed on thousands of client machines, and may not always be feasible because users may not know in advance who signed the applet that they are trying to run. Also, earlier versions of the Java plug-in supported code signing using DSA, which is not as widely prevalent as RSA.

A new class loader, sun.plugin.security.PluginClassLoader in the Java plug-in 1.3, overcomes the limitations mentioned above. It implements support for RSA verification and dynamic trust management.

The Software Development Kit (SDK) tools

The three tools dealing with security, available as part of the Java 2 SDK, are:

  • keytool -- Manages keystores and certificates
  • jarsigner -- Generates and verifies JAR signatures
  • policytool -- Manages policy files via a GUI-based tool

We will look at some of these tools' important options in the sections below. Refer to Resources for more detailed documentation associated with particular tools.