JP2023154573A - 情報処理装置、セキュリティ管理方法およびプログラム - Google Patents

Abstract

【課題】アプリに権限を付与しなくてはならないことでシステムの安定を損なう処理が実行可能になる。【解決手段】情報処理装置が、アプリケーションから始まる一連のクラスの呼び出し系列を示す呼び出し系列情報から、クラス情報記憶手段に記憶されたクラスの情報に相当する第１のクラスを特定し、呼び出し系列情報に含まれた第１のクラスから呼び出し系列情報の末尾の第２のクラスまでのそれぞれのクラスのパーミッションの共通部分を含む権限情報を生成し、その権限情報に基づいてセキュリティチェックを行う。【選択図】図２

Description

本発明は例えばアプリの実行時のセキュリティ管理に関し、特に情報処理装置、セキュリティ管理方法およびプログラムに関するものである。

ＪＡＶＡ（登録商標）等のプラットフォームにインストールしたアプリケーション（アプリと呼ぶ）を実行するアプリ実行環境が、たとえば多機能複写機（ＭＦＰ）等のデバイスにも搭載されている。アプリ実行環境はアプリの動作がシステムの安定性を損なわないよう、アプリが実行できるシステムの機能を制限する機能をもつ。アプリ実行環境はアプリおよびアプリが使用するライブラリのクラスにＰｅｒｍｉｓｓｉｏｎと呼ばれる権限情報を付与している。そしてアプリが実行されるときのクラスの呼び出しスタックに含まれるクラスのＰｅｒｍｉｓｓｉｏｎのＡＮＤをとった権限をチェックし呼び出されたシステムの機能が実行可能か判断する仕組みを持っている（特許文献１参照）。

アプリが使用するライブラリの中には、システムの安定性を損なう可能性のあるＰｅｒｍｉｓｓｉｏｎを必要とするが、ライブラリで実装されている処理から呼び出すのであればシステムの安定性は損なわれないライブラリがある。

特表２００２－５０５４７６号公報

アプリからシステムの機能が実行可能か判断するときにはメソッド呼び出しのスタックに含まれるアプリおよびライブラリのクラスに付与されたＰｅｒｍｉｓｓｉｏｎのＡＮＤ（論理積）をとった権限が必要になる。そのため、アプリのクラスにもシステムの安定性を損なう可能性のあるＰｅｒｍｉｓｓｉｏｎを付与しなくてはならない。そのため、悪意をもつアプリやアプリのバグにより、アプリからシステムの安定性を損なう可能性のあるＰｅｒｍｉｓｓｉｏｎが必要な処理を実行され、システムの安定性を損なわれる、という課題がある。

また、クラスの呼び出しスタックに含まれるクラスのうちシステム～ある特定のクラスまでのＰｅｒｍｉｓｓｉｏｎのＡＮＤをとるようその特定のクラスのソースコードを記載することが可能なアプリ実行環境もある。しかし、バイナリで提供されたライブラリに適用できないという課題がある。さらにソースコードが存在するライブラリにおいてもライブラリのコードを一つ一つ修正しなくてはならないという課題がある。

本発明は上記従来例に鑑みて成されたもので、システムの安定性を損なうことなく、またソースコードを改変することなく必要なＰｅｒｍｉｓｓｉｏｎをライブラリに付与することを可能ならしめることを目的とする。

上記目的を達成するために本発明は以下の構成を有する。本発明の一側面によれば、アプリケーションから呼び出されるライブラリに含まれるクラスの情報を記憶するクラス情報記憶手段と、
前記アプリケーションから始まる一連のクラスの呼び出し系列を示す呼び出し系列情報から、前記クラス情報記憶手段に記憶された前記クラスの情報に相当する第１のクラスを特定する特定手段と、
前記呼び出し系列情報に含まれた前記第１のクラスから前記呼び出し系列情報の末尾の第２のクラスまでのそれぞれのクラスのパーミッションの共通部分を含む権限情報を生成する生成手段と、
前記権限情報に基づいてセキュリティチェックを行うセキュリティチェック手段と、を有する
ことを特徴とする情報処理装置が提供される。

本発明によれば、システムの安定性を損なうことなく、またソースコードを改変することなく必要なＰｅｒｍｉｓｓｉｏｎをライブラリに付与することが可能になる。

本発明の画像処理装置のハードウェアの構成図 実施形態１の画像処理装置のアプリ実行環境のソフトウェア構成図 実施形態１のクラスの呼び出しスタックおよび、クラスのＰｅｒｍｉｓｓｉｏｎを示す図 実施形態１、２のＰｅｒｍｉｓｓｉｏｎチェックのシーケンス図 実施形態１のライブラリクラスリスト 実施形態１のアプリ起動処理のフローチャート 実施形態１のＰｅｒｍｉｓｓｉｏｎチェックのフローチャート 実施形態１、２のＡＮＤ対象となるＰｅｒｍｉｓｓｉｏｎを示す図 実施形態２のクラスのローディング処理のシーケンス図 実施形態２のアプリリストを示す図 実施形態２のアプリ起動処理のフローチャート 実施形態１のＰｅｒｍｉｓｓｉｏｎチェックのフローチャート 実施形態３のＰｅｒｍｉｓｓｉｏｎチェックのフローチャート 実施形態２の画像処理装置のアプリ実行環境のソフトウェア構成図

以下、添付図面を参照して実施形態を詳しく説明する。なお、以下の実施形態は特許請求の範囲に係る発明を限定するものではない。実施形態には複数の特徴が記載されているが、これらの複数の特徴の全てが発明に必須のものとは限らず、また、複数の特徴は任意に組み合わせられてもよい。さらに、添付図面においては、同一若しくは同様の構成に同一の参照番号を付し、重複した説明は省略する。

［実施形態１］
図１は本発明のセキュリティ管理方法を実現する画像処理装置１００の構成を示す図である。画像処理装置１００は具体的には印刷機能と画像読み込み機能とを有する多機能複写機（ＭＦＰ）などであってよい。なお画像処理装置１００の情報処理機能に着目してこれを情報処理装置と呼ぶこともある。ただし本発明のセキュリティ管理方法が動作するのは画像処理装置に限定するものではない。

画像処理装置１００は本発明を実現するソフトウェアを実行するＣＰＵ１０１、本発明を実現するソフトウェアを保存しているＲＯＭ１０２、本発明を実現するソフトウェアを実行するＲＡＭ１０３を含む。さらに画像処理装置１００は、本発明を実現するソフトウェアがデータを保存する外部記憶装置１０４、ユーザが操作をおこなうＵＩ１０５、印刷をおこなう印刷エンジン１０７、ネットワークインターフェース制御部１０８を含む。

ネットワークインターフェース制御部１０８は例えば有線ＬＡＮである。ユーザインターフェイス（ＵＩ）１０５は液晶タッチパネルや液晶パネルとハードキー組み合わせたものとして実現されている。上記モジュールはバス１０６によって相互に接続されておりデータのやり取りをおこなう。画像処理装置１００はネットワークインターフェース制御部１０８によってネットワーク１１０に接続されている。

図２は本発明のセキュリティ管理方法を実現するアプリ実行環境を示す図である。仮想マシン２０１は、アプリケーション（アプリ）やライブラリ等のプログラムを実行する。ＳｅｃｕｒｉｔｙＭａｎａｇｅｒ２０２は、本発明の権限チェックをおこなう。システムライブラリ２０３は、システムの機能を提供するクラスライブラリである。ライブラリＢ２０５、及びライブラリＡ２０４は、アプリから呼び出されて使用されるクラスライブラリである。アプリ２０６は、画像処理装置１００にインストールされて実行されるアプリケーションプログラムである。これら各要素からアプリ実行環境は構成されている。なおＳｅｃｕｒｉｔｙＭａｎａｇｅｒ２０２は、セキュリティマネージャ２０２或いはセキュリティ管理部２０２などとも呼ぶ。

図３はアプリ２０６が動作するときのクラスの呼び出しスタック３０８および、各クラスに付与されたＰｅｒｍｉｓｓｉｏｎの一例を示す図である。各クラスへのＰｅｒｍｉｓｓｉｏｎ（パーミッション）は、たとえばコーディングにより予め付与されていてよい。あるいは、動的に付与されてもよい。パーミッションは例えばファイル等へのアクセス権限であるが、パーミッションの対象はファイルに限らず、他のリソースを含んでいてよい。図３ではアプリ２０６のクラス３０１からライブラリＡ２０５のクラス３０２を呼び出している。さらにライブラリＡ２０５のクラス３０２からシステムライブラリ２０３のクラス３０３を呼び出している。なおクラスの呼び出しはクラスとメソッドとを指定して行われるが、ここでは単にクラスの呼び出しと呼んでいる。パーミッションはクラスに付与される。

Ｐｅｒｍｉｓｓｉｏｎ３０４はアプリ２０６のクラス３０１に設定されているＰｅｒｍｉｓｓｉｏｎである。例えばアプリからアクセス可能なファイルは「／Ａｐｐ／ａｐｐ０１」であるというＰｅｒｍｉｓｓｉｏｎである。Ｐｅｒｍｉｓｓｉｏｎとは例えば、パーミッションや許可、許諾、承認と言い換えることもできる。

Ｐｅｒｍｉｓｓｉｏｎ３０５はライブラリＡ２０５のクラス３０２に設定されているＰｅｒｍｉｓｓｉｏｎである。例えばライブラリＡからアクセス可能なファイルは「／Ａｐｐ」であるというＰｅｒｍｉｓｓｉｏｎである。Ｐｅｒｍｉｓｓｉｏｎ３０６はシステムライブラリ２０３のクラス３０３に設定されているＰｅｒｍｉｓｓｉｏｎである。例えばシステムライブラリ２０３からすべてのファイル（＊）にアクセスできるというＰｅｒｍｉｓｓｉｏｎである。

Ｐｅｒｍｉｓｓｉｏｎはクラスの保存場所や仮想マシン２０１が保持する設定データによって仮想マシン２０１により設定される。本実施形態では説明を簡単にするためにアプリ２０６、ライブラリＡ２０５、システムライブラリ２０３だけで説明しているが実際のアプリの実行時にはさらに複雑な呼び出しスタックとなる。

従来、図３に示すクラスの呼び出しが行われた場合、アプリ２０６、ライブラリＡ２０５、システムライブラリの各クラス３０３に設定されているＰｅｒｍｉｓｓｉｏｎのＡＮＤをとった値がクラス呼び出しの権限情報３０７である。また本実施形態においても、クラスリストに含まれたクラスが呼び出されていない場合には、図３に示したように権限情報が決定される。なおその条件については図７等を参照して後で説明する。

●権限チェック処理
図４はアプリ２０６が動作するときのクラス呼び出し処理と、ＳｅｃｕｒｉｔｙＭａｎａｇｅｒ２０２での権限チェック処理を示すシーケンス図である。図４では説明を簡単にするためにシステムライブラリのクラスでセキュリティチェックが要求される場合のみを記載している。ライブラリＡのクラスでセキュリティチェックが要求されることもあるが、処理としては同様に実行される。

まずアプリのクラス３０１からライブラリＡのクラス３０２のメソッドを呼び出す（Ｓ４０１）。次にライブラリＡのクラス３０２はシステムライブラリのクラス３０３のメソッドを呼び出す（Ｓ４０２）。システムライブラリのクラス３０３呼び出されたメソッドの処理のなかで権限確認のためＳｅｃｕｒｉｔｙＭａｎａｇｅｒ３０２のｃｈｅｃｋＰｅｒｍｉｓｓｉｏｎを呼び出す（Ｓ４０３）。

ＳｅｃｕｒｉｔｙＭａｎａｇｅｒ３０２は権限のチェックをおこない（Ｓ４０４）、権限チェックに成功すればメソッドをｒｅｔｕｒｎする（Ｓ４０５）。権限チェックに成功した場合には呼び出されたクラスのメソッドは順次実行されてリターンする（Ｓ４０６－Ｓ４０７）。ここで権限チェックは図７の手順で実行される。一方権限チェックに失敗すればセキュリティ例外（ＳｅｃｕｒｉｔｙＥｘｃｅｐｔｉｏｎ）を返す（Ｓ４０８）。権限チェックに失敗した場合には呼び出されたクラスのメソッドは順次セキュリティ例外（ＳｅｃｕｒｉｔｙＥｘｃｅｐｔｉｏｎ）を返す（Ｓ４０９－Ｓ４１０）。

図５はライブラリに含まれるクラスの一例を示すリスト５０１である。リスト５０１には「ライブラリＡのクラス全て」という項目５０２や「ライブラリＢに含まれるＣｌａｓｓ０１」というクラスごとの項目５０３を含んでいる。クラスのリスト５０１は、例えばライブラリが更新される都度、ライブラリに合わせて更新され、セキュリティマネージャ２０２によりアクセス可能に外部記憶装置１０４等に保存される。クラスのリスト５０１は、ユーザが人手で作成してもよいが、ライブラリを走査してリスト５０１を作成するプログラムにより自動で作成してもよい。リスト５０１には、インストールされたアプリから呼び出され得るすべてのライブラリのクラスが登録されていてもよいし、セキュリティチェックの対象となり得るクラスに限って登録されてもよい。

図６は本発明の画像処理装置１００の起動処理のフローチャートである。画像処理装置１００はユーザによって起動されるとＲＯＭ１０２から仮想マシン２０１をＲＡＭ（１０３）にロードし、ＣＰＵ１０１にて仮想マシン２０１の実行をおこない、起動処理を開始する（Ｓ６０１）。

仮想マシン２０１はＲＯＭ１０２からＲＡＭ１０３にＳｅｃｕｒｉｔｙＭａｎａｇｅｒ２０２のプログラムをロードし、ＳｅｃｕｒｉｔｙＭａｎａｇｅｒ２０２を生成する（Ｓ６０２）。

Ｓ６０２で生成されたＳｅｃｕｒｉｔｙＭａｎａｇｅｒ２０２は外部記憶装置１０４に保存されているクラスのリスト５０１を読み込む（Ｓ６０３）。仮想マシン２０１は外部記憶装置１０４からアプリ２０６を読み込み起動し（Ｓ６０４）、起動処理を終了する（Ｓ６０５）。起動されたアプリ２０２は、ユーザなどにより選択され実行されてよい。その実行は図４で説明した要領で行われる。

●セキュリティチェック処理
図７は図４のＳ４０４の処理の詳細をしめすフローチャートである。システムライブラリのクラス３０３からｃｈｅｃｋＰｅｒｍｉｓｓｉｏｎの呼び出しがあると（Ｓ４０３）、ＳｅｃｕｒｉｔｙＭａｎａｇｅｒ３０２はｃｈｅｃｋＰｅｒｍｉｓｓｉｏｎ処理を開始する（Ｓ７０１）。

まず、ＳｅｃｕｒｉｔｙＭａｎａｇｅｒ３０２はクラスの呼び出しスタック３０８を取得する（Ｓ７０２）。たとえば、ＪＡＶＡ（登録商標）では、ＳｅｃｕｒｉｔｙＭａｎａｇｅｒ．ｇｅｔＣｌａｓｓＣｏｎｔｅｘｔ（）といったメソッドにより呼び出しスタック３０８を取得できる。呼び出しスタックのことを、アプリから始まる一連のクラスの呼び出し系列を示す呼び出し系列情報と呼ぶこともできる。そしてＳ７０２で取得したスタックの初めから呼び出されたクラスに順次着目する。次にＳｅｃｕｒｉｔｙＭａｎａｇｅｒ３０２は、Ｓ７０２で取得したスタックの最後であるかを調べる（Ｓ７０３）。最後であるとは、呼び出しスタック即ち呼び出し系列に含まれたクラスすべてについて着目して処理を終えたことを意味する。最後であればＳ７１０に遷移する。最後でなければ、すなわち未処理のクラスが残っていればＳ７０４に遷移する。

ステップＳ７０４では、ＳｅｃｕｒｉｔｙＭａｎａｇｅｒ３０２は呼び出しスタックから着目クラスを取得する。ＳｅｃｕｒｉｔｙＭａｎａｇｅｒ３０２は、クラスリスト５０１を検索し、Ｓ７０４で取得したクラスが含まれるかを調べる（Ｓ７０５）。ＳｅｃｕｒｉｔｙＭａｎａｇｅｒ３０２は、Ｓ７０６ではＳ７０４で取得したクラスがクラスリスト５０１に存在していればＳ７０７に遷移する。存在していなければスタックに含まれた次のクラスに着目してＳ７０３に遷移する（Ｓ７０６）。

ＳｅｃｕｒｉｔｙＭａｎａｇｅｒ３０２はＳ７０７では権限情報を生成する。図８はアプリ２０６が動作するときのクラスの呼び出しスタック３０８および、各クラスに付与されたＰｅｒｍｉｓｓｉｏｎから権限情報８０１を生成する例を示す図である。図８のように、呼び出しスタックの先頭のクラスから、Ｓ７０６でクラスリストに含まれていると判定したクラスまでのＰｅｒｍｉｓｓｉｏｎのＡＮＤをとった権限情報８０１を生成する。なおスタックの先頭とは呼び出しのネストが最も深い部分であり、呼び出し系列の末尾に相当する。図８の例では、呼び出しスタックの先頭のクラス、すなわち呼び出し系列の末尾はシステムライブラリのクラス３０３である。またステップＳ７０６でクラスリストに含まれていると判定したクラスは、図５に示したようにライブラリＡのクラスである。そのため、ここではそれら２つのクラスのパーミッションの論理積すなわち共通部分である"／Ａｐｐ"が権限情報として得られる。すなわちアプリAには呼び出すライブラリのパーミションが付与されている必要はない。なお上記例では２つのクラスのパーミッション論理積を求めているが、それらの間に更に呼び出されたクラスが介在していれば、そのクラスのパーミッションも論理積の対象となる。

ＳｅｃｕｒｉｔｙＭａｎａｇｅｒ３０２は、Ｓ７１０では図３の権限情報３０７のようなスタックのすべてのクラスのＰｅｒｍｉｓｓｉｏｎのＡＮＤをとった権限情報を生成する。

ＳｅｃｕｒｉｔｙＭａｎａｇｅｒ３０２はＳ７０８では、ステップＳ７０７またはＳ７１０で生成した権限情報をもちいてセキュリティチェックをおこない（Ｓ７０８）、ｃｈｅｃｋＰｅｒｍｉｓｓｉｏｎ処理を終了する（Ｓ７０９）。Ｓ７０８でセキュリティチェックが成功すればメソッド呼び出しの処理が実施されｒｅｔｕｒｎする（Ｓ４０５～Ｓ４０７）。Ｓ７０８でセキュリティチェックが失敗すればセキュリティ例外（ＳｅｃｕｒｉｔｙＥｘｃｅｐｔｉｏｎ）を返す（Ｓ４０８～Ｓ４１０）。

本実施形態の例では、図５に示すようにライブラリＡのクラス３０２はクラスリスト５０１に含まれているため、図８の権限情報８０１でセキュリティチェックが実施される。権限情報８０１は、クラスリスト５０１に含まれたライブラリＡのクラスのパーミッション（／Ａｐｐ）と、そのクラスから呼び出されたシステムライブラリのクラスのパーミション（＊）との合成すなわち論理積により得られている。記号＊はすべてのファイルに対してアクセス可能であることを示すので、合成語のパーミッションは「／Ａｐｐ」、すなわち、／Ａｐｐに対してアクセスが許可される。そして本例では、／Ａｐｐに対してアクセス可能というパーミションであれば、セキュリティチェックが成功する。なお論理積を求めることは、対象となるクラスそれぞれの共通のパーミッションを決定することともいえる。

よってライブラリＡが動作するために「／Ａｐｐ」へのファイルアクセスが必要であっても、アプリのクラス３０１に「／Ａｐｐ」へのファイルアクセスを許可するＰｅｒｍｉｓｓｉｏｎを付与する必要はない。

またこのようにパーミッションを管理することで、アプリからは「／Ａｐｐ」へのファイルアクセスを許可するＰｅｒｍｉｓｓｉｏｎを持つライブラリを経由しなければ／Ａｐｐへのアクセスはできない。すなわち本例ではアプリからはライブラリＡ経由以外での「／Ａｐｐ」へのファイルアクセスはできないため、システムの安定性をそこなうことはなくなる。

［実施形態２］
本実施形態では、アプリが呼び出すクラスのライブラリクラスローダを作成し、実施形態１において参照したクラスリストに代えてそのライブラリクラスローダ参照して、アプリから呼び出されるクラスのパーミッションを特定する。そして、それに基づいて権限情報を作成する。

図９は実施形態２のアプリ実行環境でのクラスロード処理を示すシーケンス図である。アプリ２０６がアプリの実行に必要なクラスをロードするとき、まずアプリ用クラスローダ９０１に対してクラス要求をおこなう（Ｓ９０４）。アプリ用クラスローダ９０１は本実施形態のＬｉｂｒａｒｙＣｌａｓｓＬｏａｄｅｒ９０２に対してクラス要求をおこなう（Ｓ９０５）。本実施形態のＬｉｂｒａｒｙＣｌａｓｓＬｏａｄｅｒ９０２はシステムクラスローダ９０３に対してクラス要求をおこなう（Ｓ９０６）。それに応じてシステムクラスローダ９０３は自身のクラス保存場所から指定されたクラスをロードする（Ｓ９０７）。

システムクラスローダ９０３がクラスのロードに成功したら（９０８）、システムクラスローダ９０３は、ロードしたクラスにはそれをロードしたクラスローダ情報としてシステムクラスローダ９０３の情報を付与する（Ｓ９２５）。

さらに、システムクラスローダ９０３はロードしたクラスをＬｉｂｒａｒｙＣｌａｓｓＬｏａｄｅｒ９０２、アプリ用クラスローダ９０１を経てアプリ２０６に返す（Ｓ９０９～Ｓ９１１）。

一方システムクラスローダ９０３がクラスのロードに失敗したら（９１２）、システムクラスローダ９０３はＬｉｂｒａｒｙＣｌａｓｓＬｏａｄｅｒ９０２に「クラス無し」を返す（Ｓ９１３）。「クラス無し」は該当するクラスがなかったことを示す情報である。「クラス無し」の応答を受けたＬｉｂｒａｒｙＣｌａｓｓＬｏａｄｅｒ（９０２）は、それ自身のクラス保存場所から指定されたクラスをロードする（Ｓ９１４）。

ステップＳ９１４でクラスのロードに成功したら（９１５）、ＬｉｂｒａｒｙＣｌａｓｓＬｏａｄｅｒ９０２は、ロードしたクラスに、それをロードしたクラスローダ情報としてＬｉｂｒａｒｙＣｌａｓｓＬｏａｄｅｒ９０２の情報を付与する（Ｓ９２６）。さらに、ＬｉｂｒａｒｙＣｌａｓｓＬｏａｄｅｒ９０２は、ロードしたクラスを、アプリ用クラスローダ９０１を経てアプリ２０６に返す（Ｓ９１６～S９１７）。

一方、Ｌｉｂｒａｒｙ ＣｌａｓｓＬｏａｄｅｒ９０２がクラスのロードに失敗したら（９１８）、ＬｉｂｒａｒｙＣｌａｓｓＬｏａｄｅｒ９０２はアプリ用クラスローダ９０１に「クラス無し」を返す（Ｓ９１９）。これに応じてアプリ用クラスローダ９０１は自身のクラス保存場所から指定されたクラスをロードする（Ｓ９２０）。

アプリ用クラスローダ９０１がＳ９２０でクラスのロードに成功したら（９２１）、アプリ用クラスローダ９０１はロードしたクラスにロードしたクラスローダ情報としてアプリ用クラスローダ９０１の情報を付与する（Ｓ９２２）。さらにアプリ用クラスローダ９０１はロードしたクラスをアプリ２０６に返す（Ｓ９２３）。

一方アプリ用クラスローダ９０１がＳ９２０でクラスのロードに失敗したら（９２４）、アプリ用クラスローダ９０１は「クラス無し例外」をアプリ２０６に返す（Ｓ９２５）。クラス無し例外は、どのクラスローダによっても所望のクラスをロードできなかったことを示すので、クラス無し例外を受信したアプリ２０６はその状況に応じた所定の処理を実行する。

図１０は実施形態２の画像処理装置１００のアプリリスト１００１の一例である。アプリリストはインストールされたアプリのアプリ情報１００２のリストから構成されている。各アプリのアプリ情報はアプリのプログラムのパス情報１００３とアプリが使用するライブラリのパス情報１００４とを含む。ライブラリを使用しないアプリのパス情報１００５は空である。アプリリスト１００１は、図１１で説明する画像処理装置１００の起動処理において参照される。

図１４は実施形態２のセキュリティ管理方法を実現するアプリ実行環境を示す図である。ＳｅｃｕｒｉｔｙＭａｎａｇｅｒ２０２はＬｉｂｒａｒｙＣｌａｓｓＬｏａｄｅｒ記憶部１４０１をもつ。この実行環境で図１１の手順が実行される。

図１１は実施形態２の画像処理装置１００の起動処理のフローチャートである。画像処理装置１００はユーザによって起動されるとＲＯＭ１０２から仮想マシン２０１をＲＡＭ１０３にロードし、ＣＰＵ１０１にて仮想マシン２０１の実行をおこない、起動処理の開始する（Ｓ１１０１）。仮想マシン２０１はＲＯＭ１０２からＲＡＭ１０３にＳｅｃｕｒｉｔｙＭａｎａｇｅｒ２０２のプログラムをロードし、ＳｅｃｕｒｉｔｙＭａｎａｇｅｒ２０２を生成する（Ｓ１１０２）。仮想マシン２０１は外部記憶装置１０４からアプリリスト１００１を読み込む（Ｓ１１０３）。読み込んだアプリリストの先頭のアプリ情報に着目する。仮想マシン２０１は着目したアプリ情報がアプリリスト１００１の末尾に達したかを調べる（Ｓ１１０４）。末尾まで達していればＳ１１１０に遷移する。達していなければＳ１１０５に遷移する。末尾まで、とはアプリリストに含まれた全アプリのアプリ情報についてＳ１１０５～Ｓ１１０９の処理を完了したことを意味している。

Ｓ１１０５では仮想マシン２０１はアプリリスト１００１から着目したアプリ情報を取得する（Ｓ１１０５）。次に仮想マシン２０１は取得したアプリ情報にライブラリ情報が含まれているかを調べる（Ｓ１１０６）。アプリ情報にライブラリ情報が含まれていればＳ１１０７に遷移する。含まれていなければＳ１１０９に遷移する。

Ｓ１１０７で仮想マシン２０１はライブラリ情報に含まれているパスからクラスをロードするＬｉｂｒａｒｙＣｌａｓｓＬｏａｄｅｒ９０２を生成する。ＬｉｂｒａｒｙＣｌａｓｓＬｏａｄｅｒ９０２は、セキュリティチェック対象となるライブラリのクラスをロードするクラスローダである。このＬｉｂｒａｒｙＣｌａｓｓＬｏａｄｅｒ９０２を用いて図１０のクラスロード処理が実行される。次に仮想マシン２０１はＳ１１０７で生成したＬｉｂｒａｒｙＣｌａｓｓＬｏａｄｅｒ９０２をＳｅｃｕｒｉｔｙＭａｎａｇｅｒ２０２のＬｉｂｒａｒｙＣｌａｓｓＬｏａｄｅｒ記憶部１４０１に保存する（Ｓ１１０８）。Ｓ１１０９で仮想マシン２０１は外部記憶装置１０４からアプリ２０６を読み込み起動し（Ｓ１１０９）、Ｓ１１０４に遷移する。このときアプリリストの着目アプリを次のアプリに移動する。

アプリリストに含まれた全アプリについて着目して処理を終了したなら、Ｓ１１１０で仮想マシン２０１は起動処理を終了する。このようにして画像処理装置１００の起動時にアプリリストに登録されたアプリを順次起動し、またライブラリ情報が登録されたアプリについては、そのライブラリクラスローダを生成してセキュリティマネージャ２０２に登録しておく。

●権限情報の生成処理
実施形態２でも図４のようにＰｅｒｍｉｓｓｏｉｎのチェックがおこなわれる。図１２は実施形態２における図４のＳ４０４の処理の詳細をしめすフローチャートである。

システムライブラリのクラス３０３からｃｈｅｃｋＰｅｒｍｉｓｓｉｏｎの呼び出しがあると（Ｓ４０３）、ＳｅｃｕｒｉｔｙＭａｎａｇｅｒ３０２はｃｈｅｃｋＰｅｒｍｉｓｓｉｏｎ処理を開始する（Ｓ１２０１）。まず、ＳｅｃｕｒｉｔｙＭａｎａｇｅｒ３０２はクラスの呼び出しスタック３０８を取得する（Ｓ１２０２）。呼び出しスタックのことを呼び出し経路とも呼ぶ。たとえば、ＪＡＶＡ（登録商標）では、ＳｅｃｕｒｉｔｙＭａｎａｇｅｒ．ｇｅｔＣｌａｓｓＣｏｎｔｅｘｔ（）といったメソッドにより呼び出しスタック３０８を取得できる。そしてＳ７０２で取得したスタックの初めから呼び出されたクラスに順次着目する。次にＳｅｃｕｒｉｔｙＭａｎａｇｅｒ３０２はＳ１２０３で取得したスタックの最後であるかを調べる（Ｓ１２０３）。最後であるとは、スタックに含まれたクラスすべてについて着目して処理を終えたことを意味する。最後であればＳ１２１０に遷移する。最後でなければ、すなわち未処理のクラスが残っていればＳ１２０４に遷移する。

ステップＳ１２０４で、ＳｅｃｕｒｉｔｙＭａｎａｇｅｒ３０２は呼び出しスタックから着目クラスを取得する。ＳｅｃｕｒｉｔｙＭａｎａｇｅｒ３０２は取得したクラスのクラスローダを取得する（１２０５）。次にＳｅｃｕｒｉｔｙＭａｎａｇｅｒ３０２はＬｉｂｒａｒｙＣｌａｓｓＬｏａｄｅｒ記憶部１４０１に保存されているクラスローダに、Ｓ１２０５で取得したクラスローダが含まれているかを調べる（Ｓ１２０６）。ＳｅｃｕｒｉｔｙＭａｎａｇｅｒ３０２は、保存されているクラスローダにＳ１２０５で取得したクラスローダが含まれていればＳ１２０７に遷移する。含まれていなければスタックに含まれた次のクラスに着目してＳ１２０３に遷移する（Ｓ１２０６）。

ＳｅｃｕｒｉｔｙＭａｎａｇｅｒ３０２は、Ｓ１２０７では、実施形態１と同様に権限情報８０１を生成する。生成は、図８のスタックの先頭のクラスから、Ｓ１２０６でＬＩｂｒａｒｙＣｌａｓｓＬｏａｄｅｒ記憶部１４０１に記憶されていると判定したクラスまでのＰｅｒｍｉｓｓｉｏｎのＡＮＤをとることで行う。なおスタックの先頭とは呼び出しのネストが最も深い部分であり、図８の例では、呼び出しスタックの先頭のクラスはシステムライブラリのクラス３０３である。

ＳｅｃｕｒｉｔｙＭａｎａｇｅｒ３０２はＳ１２１０では、図３の権限情報３０７のようなスタックのすべてのクラスのＰｅｒｍｉｓｓｉｏｎのＡＮＤをとった権限情報を生成する。

ＳｅｃｕｒｉｔｙＭａｎａｇｅｒ３０２はＳ１２０８では、ステップＳ１２０７またはＳ１２０１で生成した権限情報をもちいてセキュリティチェックをおこない（Ｓ１２０８）、ｃｈｅｃｋＰｅｒｍｉｓｓｉｏｎ処理を終了する（Ｓ１２０９）。Ｓ１２０８でセキュリティチェックが成功すればメソッド呼び出しの処理が実施されｒｅｔｕｒｎする（Ｓ４０５～Ｓ４０７）。Ｓ１２０８でセキュリティチェックが失敗すればセキュリティ例外（ＳｅｃｕｒｉｔｙＥｘｃｅｐｔｉｏｎ）を返す（Ｓ４０８～Ｓ４１０）。

本実施形態の例では、図１０に示すようにアプリＡ２０５はライブラリＡと関連付けてアプリリスト１００１に登録されているため、図１１の手順でライブラリＡのライブラリクラスローダがＬｉｂｒａｒｙＣｌａｓｓＬｏａｄｅｒ１４０１に登録される。こうしてライブラリＡのクラス３０２をロードしたＬｉｂｒａｒｙＣｌａｓｓＬｏａｄｅｒはＳｅｃｕｒｉｔｙＭａｎａｇｅｒ３０２に登録されているため、図８の権限情報８０１が生成されてそれを用いてセキュリティチェックを実施する。

よってライブラリＡが動作するために「／Ａｐｐ」へのファイルアクセスが必要であっても、アプリのクラス３０１に「／Ａｐｐ」へのファイルアクセスを許可するＰｅｒｍｉｓｓｉｏｎを付与する必要はない。それによりアプリからはライブラリＡ経由以外での「／Ａｐｐ」へのファイルアクセスはできないため、システムの安定性をそこなうことはなくなる。さらに実施形態１と比べるとクラスローダを使用して判定をおこなうため対象となるクラスの数が多くなってもＳｅｃｕｒｉｔｙＭａｎａｇｅｒの処理時間が大きくならない。

［実施形態３］
図１３は実施形態３における図４のＳ４０４の処理の詳細をしめすフローチャートである。本実施形態では、実施形態２の図１２に示したセキュリティチェックの手順を、デフォルト設定のセキュリティチェックで失敗した（不許可となった）後で実行する。

図１３において、ｃｈｅｃｋＰｅｒｍｉｓｓｉｏｎの呼び出しがあると（Ｓ４０３）、ＳｅｃｕｒｉｔｙＭａｎａｇｅｒ３０２はｃｈｅｃｋＰｅｒｍｉｓｓｉｏｎ処理を開始する（Ｓ１２０１）。

まず、ＳｅｃｕｒｉｔｙＭａｎａｇｅｒ３０２はセキュリティのチェックをおこなう（Ｓ１３０１）。次にＳ１３０１のセキュリティチェックが成功したか判定し（Ｓ１３０２）、成功すればＳ１２０８に遷移しｃｈｅｃｋＰｅｒｍｉｓｓｉｏｎ処理を終了する（Ｓ１２０８）。ステップＳ１３０１のセキュリティチェックは、例えばステップＳ１２１０と同様の権限情報を生成して実行してよい。その場合には、図１３のステップＳ１２０３でスタックの最後と判定したなら、ステップＳ１２０９へと分岐してよい。これにより同じチェックの繰り返しを避けることができる。

Ｓ１３０１のセキュリティチェックが失敗すればＳ１２０２に遷移し、例えば実施形態２のｃｈｅｃｋＰｅｒｍｉｓｓｉｏｎ処理を行う。この処理により、ライブラリを使用しない処理の場合は高速にｃｈｅｃｋＰｅｒｍｉｓｓｉｏｎ処理を行うことができる。なお、実施形態２の図１２に示したセキュリティチェックの手順に代えて、実施形態１の図７に示したセキュリティチェックの手順を行ってもよい。

以上説明したように、実施形態１乃至３の構成及び処理手順によって、システムライブラリのクラスを利用するために必要なパーミッション（許諾）をアプリに付与することなく、当該クラスを利用することが可能となった。また実施形態１乃至３によれば、そのためにライブラリのコードを修正する必要もない。この結果、ライブラリのクラスの許諾を付与されたアプリが、その許諾を利用してセキュリティチェックを通すことを防止でき、システムの安全性や安定性を損なうことを防止できる。またライブラリのコードを修正する必要がなく、そのための工数が不要となる。

また実施形態２では、アプリから呼び出されるクラスをライブラリクラスローダでロードすることにより、アプリのライブラリのクラス経由の呼び出しにのみアプリのパーミッションをチェックせずに実行可能となる。また、ライブラリの修正なしにライブラリを使用することができる。さらに実施形態２では、アプリから呼び出されるライブラリクラスのクラスローダの情報で判断するために、ライブラリ含まれたクラスの数が増加してもチェック対象のクラスの数は限られ、パーミッションのチェックに要する時間が増えることがない。

また実施形態３では、まず従来のセキュリティマネージャによる手順でセキュリティチェックが行われるため、パーミッションが付与されたアプリについては、起動の所要時間に影響を与えずにセキュリティチェックが可能となる。また従来の手順でセキュリティチェックに失敗すると、実施形態１または実施形態２の手順でセキュリティチェックを行うために、
［その他の実施例］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

発明は上記実施形態に制限されるものではなく、発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、発明の範囲を公にするために請求項を添付する。

●実施形態のまとめ
本実施形態の開示は、以下の構成および方法を含む。
（構成１）アプリケーションから呼び出されるライブラリに含まれるクラスの情報を記憶するクラス情報記憶手段と、
前記アプリケーションから始まる一連のクラスの呼び出し系列を示す呼び出し系列情報から、前記クラス情報記憶手段に記憶された前記クラスの情報に相当する第１のクラスを特定する特定手段と、
前記呼び出し系列情報に含まれた前記第１のクラスから前記呼び出し系列情報の末尾の第２のクラスまでのそれぞれのクラスのパーミッションの共通部分を含む権限情報を生成する生成手段と、
前記権限情報に基づいてセキュリティチェックを行うセキュリティチェック手段と、を有することを特徴とする情報処理装置。

（構成２）
構成１に記載の情報処理装置であって、
前記クラス情報記憶手段は、アプリケーションから呼び出され得るライブラリに含まれるすべてのクラスの情報を記憶する
ことを特徴とする情報処理装置。

（構成３）
構成１に記載の情報処理装置であって、
前記クラス情報記憶手段は、前記クラスの情報として、前記情報処理装置にインストールされたアプリケーションが使用するライブラリのクラスローダを記憶する
ことを特徴とする情報処理装置。

（構成４）
構成３に記載の情報処理装置であって、
前記情報処理装置にインストールされた前記アプリケーションのパス情報と当該アプリケーションが使用するライブラリのパス情報とを含むリストを記憶するリスト記憶手段を更に有し、
前記情報処理装置の起動時に、前記リストに含まれた前記ライブラリのパス情報に基づいて前記クラスローダを生成し、前記クラス情報記憶手段に記憶する
ことを特徴とする情報処理装置。

（構成５）
構成１乃至４のいずれかに記載の情報処理装置であって、
前記特定手段により前記第１のクラスを特定できない場合には、前記生成手段は、前記呼び出し系列情報に含まれたすべてのクラスのパーミッションの共通部分を含む権限情報を生成する
ことを特徴とする情報処理装置。

（構成６）
構成１乃至５のいずれかに記載の情報処理装置であって、
前記呼び出し系列情報に含まれたすべてのクラスのパーミッションの共通部分を含む権限情報を生成して前記権限情報で前記セキュリティチェック手段によるセキュリティチェックを行うチェック手段を更に有し、
前記チェック手段によるセキュリティチェックが失敗した場合に、前記特定手段と前記生成手段と前記セキュリティチェック手段とによるセキュリティチェックを行う
ことを特徴とする情報処理装置。

（構成７）
構成１に記載の情報処理装置であって、
前記パーミッションには、アクセスが許可されたファイルの情報を含む
ことを特徴とする情報処理装置。

（構成８）
構成１に記載の情報処理装置であって、
前記アプリケーションから始まる一連のクラスの呼び出し系列は、前記アプリケーションから要求されたクラスがロードされるまでの呼び出し系列を含む
ことを特徴とする情報処理装置。

（構成９）
構成１乃至８のいずれかに記載の情報処理装置としてコンピュータを機能させるためのプログラム。

２０１ 仮想マシン、２０２ ＳｅｃｕｒｉｔｙＭａｎａｇｅｒ、２０３ システムライブラリ、２０４ ライブラリＢ、２０５ ライブラリＡ、２０６ アプリ

Claims (10)

1. アプリケーションから呼び出されるライブラリに含まれるクラスの情報を記憶するクラス情報記憶手段と、
   前記アプリケーションから始まる一連のクラスの呼び出し系列を示す呼び出し系列情報から、前記クラス情報記憶手段に記憶された前記クラスの情報に相当する第１のクラスを特定する特定手段と、
   前記呼び出し系列情報に含まれた前記第１のクラスから前記呼び出し系列情報の末尾の第２のクラスまでのそれぞれのクラスのパーミッションの共通部分を含む権限情報を生成する生成手段と、
   前記権限情報に基づいてセキュリティチェックを行うセキュリティチェック手段と、を有する
   ことを特徴とする情報処理装置。
2. 請求項１に記載の情報処理装置であって、
   前記クラス情報記憶手段は、アプリケーションから呼び出され得るライブラリに含まれるすべてのクラスの情報を記憶する
   ことを特徴とする情報処理装置。
3. 請求項１に記載の情報処理装置であって、
   前記クラス情報記憶手段は、前記クラスの情報として、前記情報処理装置にインストールされたアプリケーションが使用するライブラリのクラスローダを記憶する
   ことを特徴とする情報処理装置。
4. 請求項３に記載の情報処理装置であって、
   前記情報処理装置にインストールされた前記アプリケーションのパス情報と当該アプリケーションが使用するライブラリのパス情報とを含むリストを記憶するリスト記憶手段を更に有し、
   前記情報処理装置の起動時に、前記リストに含まれた前記ライブラリのパス情報に基づいて前記クラスローダを生成し、前記クラス情報記憶手段に記憶する
   ことを特徴とする情報処理装置。
5. 請求項１に記載の情報処理装置であって、
   前記特定手段により前記第１のクラスを特定できない場合には、前記生成手段は、前記呼び出し系列情報に含まれたすべてのクラスのパーミッションの共通部分を含む権限情報を生成する
   ことを特徴とする情報処理装置。
6. 請求項１乃至５のいずれか一項に記載の情報処理装置であって、
   前記呼び出し系列情報に含まれたすべてのクラスのパーミッションの共通部分を含む権限情報を生成して前記権限情報で前記セキュリティチェック手段によるセキュリティチェックを行うチェック手段を更に有し、
   前記チェック手段によるセキュリティチェックが失敗した場合に、前記特定手段と前記生成手段と前記セキュリティチェック手段とによるセキュリティチェックを行う
   ことを特徴とする情報処理装置。
7. 請求項１に記載の情報処理装置であって、
   前記パーミッションには、アクセスが許可されたファイルの情報を含む
   ことを特徴とする情報処理装置。
8. 請求項１に記載の情報処理装置であって、
   前記アプリケーションから始まる一連のクラスの呼び出し系列は、前記アプリケーションから要求されたクラスがロードされるまでの呼び出し系列を含む
   ことを特徴とする情報処理装置。
9. アプリケーションから呼び出されるライブラリに含まれるクラスの情報を記憶するクラス情報記憶手段と、
   前記アプリケーションから始まる一連のクラスの呼び出し系列を示す呼び出し系列情報から、前記クラス情報記憶手段に記憶された前記クラスの情報に相当する第１のクラスを特定する特定手段と、
   前記呼び出し系列情報に含まれた前記第１のクラスから前記呼び出し系列情報の末尾の第２のクラスまでのそれぞれのクラスのパーミッションの共通部分を含む権限情報を生成する生成手段と、
   前記権限情報に基づいてセキュリティチェックを行うセキュリティチェック手段と、してコンピュータを機能させるためのプログラム。
10. アプリケーションから呼び出されるライブラリに含まれるクラスの情報を記憶するクラス情報記憶手段と、特定手段と、生成手段と、セキュリティチェック手段とを有する情報処理装置によるセキュリティ管理方法であって
    前記特定手段が、前記アプリケーションから始まる一連のクラスの呼び出し系列を示す呼び出し系列情報から、前記クラス情報記憶手段に記憶された前記クラスの情報に相当する第１のクラスを特定し、
    前記生成手段が、前記呼び出し系列情報に含まれた前記第１のクラスから前記呼び出し系列情報の末尾の第２のクラスまでのそれぞれのクラスのパーミッションの共通部分を含む権限情報を生成し、
    前記セキュリティチェック手段が、前記権限情報に基づいてセキュリティチェックを行う
    ことを特徴とするセキュリティ管理方法。

Images