情報処理学会論文誌

Vol.53 No.9 1–18 (Sep. 2012)

アプリケーションの実行状況に基づく強制アクセス制御方式
原田 季栄1,2,a)

半田 哲夫3,b)

橋本 正樹1,c)

田中 英彦1,d)

受付日 2011年12月2日, 採録日 2012年6月4日

概要：従来のアクセス制御は，主体であるアプリケーションとそれがアクセスしようとするファイルなどの客体の組み合わせによってアクセス可否を判断していた．そのためアプリケーションの処理の内容およびアクセスを認めることにより情報システムに与える影響を考慮することができなかった．本稿では，ア
プリケーションが実行される状況に基づき，各アプリケーションが行おうとしている処理の内容を考慮することができるアクセス制御方式について提案する．提案方式を用いることにより，不正アクセスや誤操作などによるリスクを軽減することが可能となる．本稿では，提案システムの概念と実現方法について紹介し，その Linux 上の実装である TOMOYO Linux[1][2] における評価結果を報告する．

Mandatory Access Control Method Based on
Application Execution State
Toshiharu Harada1,2,a)

Tetsuo Handa3,b)Masaki Hashimoto1,c)Hidehiko Tanaka1,d)Received: December 2, 2011, Accepted: June 4, 2012

Abstract: Existing access control methods grant access requests based on the combinations of applications
as subject and ﬁles as objects. Therefore intents of applications and the possible eﬀects caused by granting
the access requests have not been taken into consideration. In this paper, we propose a new access control
method based on application history and intents. With our access control method, system administrators
can reduce the risks caused by malicious access attempts and wrong operations. In this paper, the concept
and implementation design will be explained as well as the brief evaluation report of TOMOYO Linux, ourimplementation of the new access control method to Linux.

1. はじめに保が課題となっており，例えば，ファイルやディレクトリ
のアクセス権の設定が適切でなければ，情報の漏えいやシ

近年，情報システムの適用領域が拡大し，その処理内容

ステムの不具合が容易に生じ得るし，それらが適切であっも高度化しているため，それを実現するソフトウェアは大たとしても，不正アクセス，ワームなどにより情報システ

規模・複雑化している．そのため，情報セキュリティの担ムが乗っ取られてしまうリスクが潜在的に存在する．これ

1

2

3

a)
b)
c)
d)

情報セキュリティ大学院大学
INSTITUTE of INFORMATION SECURITY
株式会社 NTT データ
NTT DATA CORPORATION
NTT データ先端技術株式会社
NTT DATA INTELLILINK CORPORATION
dgs085101@iisec.ac.jp
penguin-kernel@i-love.sakura.ne.jp
hashimoto@iisec.ac.jp
tanaka@iisec.ac.jp

c 2012 Information Processing Society of Japan

らのリスクは，完全に解消させることは不可能であり，ソフトウェアの規模が大きくなり，アプリケーションの処理内容が複雑になることにより，今後確実に増大する．
情報セキュリティを担保する手法として，サンドボック
ス [3][4] とアクセス制御がある．サンドボックスは，アプ
リケーションを限定された環境で実行するもので，ネットワークからダウンロードしたファイルなど信頼できない1

情報処理学会論文誌

Vol.53 No.9 1–18 (Sep. 2012)

アプリケーションについて，他と隔離された環境（サンドボックス）の中で実行させることにより，アプリケーショ
ンを閉じ込め [5]，被害がおよぶ範囲を限定することができまとめ，結論を述べる．

2. 従来のアクセス制御方式の限界と課題

る．また，アクセス制御は，サンドボックスを実現するた本章では，はじめに，今日多くの OS で用いられているめの要素技術で，アプリケーションの実行に伴い発生する

二つのアクセス制御方式を中心に，既存研究について振り

アクセス要求について，その実行可否を判定するものであ返り，本稿で用いるアクセス制御に関係する基本的な用語

る．情報システムは，アプリケーションがファイルの読みについて整理する．その後，従来方式の限界について述べ，書き，他のアプリケーションの実行，ネットワーク通信な解決すべき課題を整理する．

どを要求し，カーネルがそれを処理することにより機能する．したがって，個々のアプリケーションのアクセス要求

2.1 従来のアクセス制御方式について
今日，多くの情報システムで用いられるアクセス制御方式

を適切に制御することにより，システム管理者が望まない
情報システムの利用を防ぐことができる．

は，自由裁量のアクセス制御 (DAC: Discretionary Access

従来のアクセス制御方式では，アプリケーションとそれControl) と強制アクセス制御 (MAC: Mandatory Accessがアクセスしようとする対象ファイルの組み合わせに基づ

Control) の 2 つに大別される [8]．DAC は，ファイルなど

いてアクセス可否を決定していた．アクセスを要求していの所有者がそれに対してアクセスできるユーザを制御するアプリケーションの実行状況については考慮されておらるもので，アイデンティティ情報を用いてアクセス可否をず，それをアクセス制御の条件（判断基準）とできないた

判定することから，アイデンティティに基づくアクセス制

め，情報セキュリティを損なう事態が生じていた．例えば，御 (identity-based access control) とも呼ばれる．一方で，Web ブラウザ（HTTP クライアント）などのように多種

MAC は，所有者であってもアクセスできるユーザを制御

多様な処理を行うアプリケーションは，本来はその実行状できないもので，システム管理者が定めたルールに基づき況により認めるアクセスを変えるべき [6] であるが，従来個々のアクセス可否を判定する．MAC はアクセス可否ののアクセス制御方式では，それを考慮した実行可否を定義

ルールを必要とすることから，ルールに基づくアクセス制

することができない．結果として，従来のアクセス制御方

御 (rule-based access control) とも呼ばれる．

MAC には，アクセス可否を判断する際の基準となる式に基づくサンドボックスは粒度が粗く，被害範囲の局所化や封じ込めが不十分であった．

ルールが必要であり，それは一般にポリシーと呼ばれそこで本稿では，情報セキュリティを担保するための基

る．ポリシーでは，アクセス制御の対象となる主体およ

礎技術であるアクセス制御について，アプリケーションのび客体に何らかの識別子を必要とする．1983 年にアメリ実行状況を考慮可能な新しいアクセス制御方式について提カ国防総省が発表した TCSEC (Trusted Computing Sys-

案する．提案方式では，アプリケーションの実行状況を，

tems Evaluation Criteria)[9] で定義されたラベルに基づくシステム起動時以降から該当アプリケーションの実行に至MAC(Labeled Security) では，この識別子を「ラベル」とるまでの履歴と，アプリケーションのコマンドライン引数呼んでいる．TCSEC 以降，MAC の実装はラベルに基づや要求発生時の環境変数等の情報から解釈し，これらの情

く MAC しかなかったが，2006 年よりパス名を識別子と報を条件に用いることによりアクセス可否を判定する．まして用いる強制的なアクセス制御が提案され，それらはた，提案方式では，情報の取得／判定／強制をカーネルか

パス名に基づく MAC(pathname-based MAC)*1 と呼ばれら行うので [7]，安全に漏れなくアクセス制御の強制を行うている．例えば，Linux カーネルの標準ソースコードにことができる．

は，SELinux[10][11][12]，SMACK[13], TOMOYO Linux,

本稿の構成について説明する．2 章では，従来のアクセ

AppArmor[14] の 4 つの MAC の実装が現在含まれており，ス制御方式について振り返り，その課題について述べる．

このうち，SELinux と SMACK はラベルに基づく MAC に

次に，3 章では，提案方式を実現するための基本的なアイ

該当し，TOMOYO Linux と AppArmor はパス名に基づ

デアについて述べる．また，4 章では，提案方式の Linux

く MAC となる．

オペレーティングシステム（以下 OS）に対する実装としポリシーは，許可されるものと許可されないものを記述て，筆者らの開発している TOMOYO Linux を取り上げてした条件の集合体と定義される．ポリシーを解釈し，それ説明し，ポリシー記述例により提案方式が可能とするアクを実現するものは，ポリシーメカニズムと呼ばれる．アクセス制御の例を示す．5 章では，本方式の評価として，本セス制御方式の議論では，一般に主体（Subject）と客体方式の特長と使いやすさに関する初期検証の結果，性能へ（Object）という言葉が用いられる．本稿もそれにしたがの影響について述べる．さらに，6 章では，提案方式と他

う．ここまでの説明では，「アプリケーション」について，の方式との比較，不正アクセスに対する耐性と検討課題について考察を行う．最後に，7 章では，本稿の提案内容を

c 2012 Information Processing Society of Japan*1

http://lwn.net/Articles/277833/

2

情報処理学会論文誌

Vol.53 No.9 1–18 (Sep. 2012)

広くコンピュータプログラムを指して用いていたが，本論定として解釈し，Web コンテンツとしては扱わない（クラに入るにあたり言葉の定義を明確にしておく．これ以降，イアントに送らない）．しかし，そのファイルが index.txt

本論文における「アプリケーション」は，OS のプロセス実という名前にリネームされるとその内容はコンテンツとし行命令（Linux では execve システムコール）が認識するてクライアントに配信されてしまうことになる．ラベルに

実行形式ファイルを指して用いる．アプリケーションの実基づく MAC を用いて，これを防ぐためには，設定ファイ

行単位，あるいはインスタンスについては，プロセス（OSルである.htaccess と，index.txt などコンテンツのファプロセス）と呼ぶ．

イルとで異なるラベルが割り当てられており，かつ Web

上記の各種 MAC が，カーネル内で自動的に（受動的サーバの Apache のプロセスがファイルをオープンした後に）適用されるのに対して，アプリケーション自身の申告にオープンされたファイルのラベルを取得し，そのラベルに基づいたアクセス制御を行う方式として，Linux の sec-の内容に応じて，それをどのように扱うかを決めるよう

comp[15], FreeBSD の Capsicum[16] がある．seccomp でに実装されていなければならない．しかし，現状ではどのは，プロセスが自ら prctl(PR_SET_SECCOMP, 1); というファイルにどのラベルを割り当てるかについては，共通

システムコールを発行すると，それ以降，read(), write(),の規約や同意は存在しておらず*2 ，ほとんどのアプリケー

exit(), sigreturn() の 4 つのシステムコール以外のシス

ションはファイル名に基づいて動作や扱い方を決めるよう

テムコールを実行できなくなる．現状の seccomp はグリッに実装されている．

ドなど特殊な用途にしか適用できないが，利用できるシス

二つ目の例として，SSH（セキュアシェル）サービスのテムコールを汎用化する提案がなされている．Capsicum

サーバは，クライアントからの要求受付時に，指定されたではアプリケーションごとにプロセスのケーパビリティをファイルの内容をバナーとして表示するオプションを持つ．

制限することが可能であり，seccomp と同様にプロセスの

例えば，/usr/sbin/sshd -o ’Banner /etc/shadow’ の申告に基づく．Capsicum では，アプリケーションごとにように実行すると，認証を行う前のクライアントに対してオープンできるファイルを制御するといった用途には適用/etc/shadow に保存されているパスワードを開示してしできないので，直接本研究の課題を単独で解決することはまうことになる．一つ目の例は，ファイル名がアプリケー

できない．

ションの処理内容に影響を与える例で，二つ目の例は，アプリケーションに与えられたコマンドライン引数がアプリ

2.2 従来のアクセス制御方式の限界
DAC は，もっとも基本的なアクセス制御方式として広ケーションの処理内容を決定する例で，それらは従来のアクセス制御では対処することができない．

く使われている．DAC では，ユーザ情報に基づいてアクラベルに基づく MAC は識別子として名前（ファイル名）

セス可否を判断するため，定義できるアクセス許可の内容を用いない．それは，名前が主体および客体の属性でありは読み書き実行と粗い上に，管理者権限を持つユーザは影変わり得るものであることが最大の理由である．実体にラ響を受けないという限界がある．このため，バッファオー

ベルを割り当てることによって，リネームなど名前に関す

バーフロー攻撃 [17] などにより制御を奪われてしまった場

る操作に影響されないアクセス制御が可能となり，客体の合，被害を限定する効果が弱く，特に管理者権限を持って情報の漏えいを防ぐことができるが，ラベルが維持され，実行されているプロセスの制御を奪われた場合には，深刻客体へのアクセス条件が保たれたとしても，それだけではな被害を避けられない．

十分ではない．

ラベルに基づく MAC は，DAC における限界を補うこ

先に見た二つの例は，それぞれ Apache と sshd というアとができる．ラベルに基づく MAC では，主体と客体に割

プリケーションの処理内容に関するものであり，かつファり当てられたラベルに基づきアクセス可否を判断する．必イルのリネームおよびアプリケーションの実行というアク要に応じて，主体および客体のラベルを定義すれば，任意セスを許可したことによる生じる影響である．従来のアクの粒度でのアクセス制御を行うことが可能であり，管理者

セス制御では，それらを考慮していないので，制限するこ

権限で実行されているプロセスも例外扱いされず制御の対とができない．

象となる．しかしながら，ラベルに基づく MAC を用いる
ことにより，主体から客体へのアクセス可否の判断を適切

2.3 解決すべき課題に制御できたとしても，それだけでは情報セキュリティを

従来のアクセス制御方式は，主体と客体の組み合わせに保つことができるとは言えない．それについて二つの例を基づいてアクセス可否の判断を行っており，主体であるア示す．

プリケーションについてはそれがどのような処理を行おう

一つ目の例として，Web サーバの Apache は，コンテンツが保存されているディレクトリに.htaccess という名前を持つファイルが存在する場合，そのファイルの内容を設

c 2012 Information Processing Society of Japanとしているかは考慮されていなかった．2.2 節で示した一*2

Fedora15 においては，/var/www/html の配下に.htaccess を作成した場合，コンテンツと同じラベルが割り当てられる

3

情報処理学会論文誌

Vol.53 No.9 1–18 (Sep. 2012)

つ目の例では，客体に保存されていた情報がどのように使するために得たシェルは，プログラムファイルとしては同われるようになるかが考慮されないまま，リネームの要求一であっても与えるべきアクセス許可は区別して扱うべきを認めていることが問題であり，二つ目の例では，認証前である．また，本稿の対象とするアクセス制御は，情報セのクライアントにパスワードファイルの内容を表示してしキュリティを保つものであり，すべてのアプリケーション

まうことになるということが考慮されないまま，SSH サーを対象とすることが望ましい．すなわち，すべてのアプリ

バの実行を認めていることが問題である．すなわち，従来

ケーションについて，その実行状況により場合を分離できのアクセス制御方式には以下の課題が存在する．

るようにする必要がある．本稿では，アプリケーションご• アクセス要求の可否判断において，客体に保存されていた情報がどう使われるのかが考慮されていないとにその実行履歴を管理することにより，アプリケーショ
ンの実行状況を分類する方法を提案する．

• アクセス要求の可否判断において，情報システムやア

ここで実行履歴とは，アプリケーションのプロセスごと

プリケーションの動作にどのような影響が生じるかがに，それを実行するに至ったアプリケーションのプログラ考慮されていない

ム名をリスト化したものである．表 1 に，Linux ディスト

アクセス制御機構において，以下の仕組みを取り込むこ

リビューションのひとつである Fedora 15 における例*3 をとで上記の課題を解決することができる．

示す．3 つの例は，いずれもシェルである/bin/bash のプ( i ) アプリケーションごとに，その実行されている状況をロセスに関するものである．項番 1 から 3 までの先頭に取得（分類）する仕組み

ある/sbin/init は，Linux 起動時に作成されるプロセス

同じアプリケーションであっても，それが実行されであるが，そこから/bin/bash が実行されるにいたった履ている状況によって，必要となるアクセス許可定義は歴は 3 つとも異なっている．項番 1 では，サービスを起異なる．そのため，何らかの基準を用いてアプリケー

動する起動用スクリプトである/etc/rc.d/init.d/sshd

ションの実行されている状況を分類し，その分類ごとから実行されたデーモンである sshd が，クライアントかにアクセス制御を行うことが必要となる．

らのアクセス要求により新たなプロセスを生成し，そこ( ii ) アプリケーションについて，それが行おうとしている
内容を判断する仕組みから実行された/bin/bash であることを示している．項
番 2 では，ログインを受け付けるアプリケーションである

それぞれの状況ごとに分類ができたとして，それぞ/sbin/agetty が，ログイン処理を行うためのアプリケー

れのアプリケーションから発せられるアクセス要求にションである/bin/login を実行し，そこから実行された

ついて，その意図を推測し，アクセスを許可した場合/bin/bash であることを示している．項番 3 では，項番 2の影響を判断するための基準が必要である．

として実行された/bin/bash が受け付けた「他のユーザと( iii )すべてのアプリケーションについて，その状態と行おしてコマンドを実行するためのアプリケーション」である

うとしている内容を考慮したアクセス可否判断を行う

su(switch user) の実行結果として，実行された/bin/bash

仕組みであることを示している．

上記 (i)(ii) に基づいたアクセス制御機構は，それがLinux カーネルは標準の状態では，3 つの例/bin/bash

漏れなく，回避できないように実装される必要がある．

のプロセスについて，それらがどのような状況で実行され3. 実行状況に基づくアクセス制御方式の提案たものであるかを判定することができない．したがってそれらの置かれた状況により区別することができず，それぞ

本章では，第 2 章で述べた従来のアクセス制御の限界をれのプロセスについて状況に応じたアクセス許可を定義す

補う，新しいアクセス制御を実現するための基本的なアイることもできない．しかし，各プロセスについて，それぞデアとして，実行履歴を用いたアプリケーションの分類と，れの実行履歴の内容を参照することができれば，コンソー

その処理内容によるアクセス可否の判定について説明する．

ルからログインした場合には制限なくすべてのアプリケー
ションを実行できるが，SSH クライアントからログインし3.1 実行履歴を用いたアプリケーションの分類
アプリケーションごとにその処理内容を考慮したアクセス制御を行うためには，アクセス制御機構において，アプた場合には特定のアプリケーションしか実行できないように制限するなど，それぞれに認めるアクセス許可を区別することができる．

リケーションを意識しなければならない．同じアプリケー
ションであっても，それが実行される状況によって扱いを

3.2 アプリケーションの処理内容によるアクセス可否判定

変える必要がある．たとえば，サーバのコンソールからロアプリケーションの処理内容は，アプリケーションの作

グインして得られたシェル（Linux におけるコマンドイン者が定義し，アプリケーションのファイルの中に記録されタプリタ）と，SSH クライアントからログインして得られ*3たシェル，あるいは Web サーバの Apache が CGI を実行

c 2012 Information Processing Society of Japan

これらの結果は，ディストリビューションや実行環境により異なる．

4

情報処理学会論文誌

Vol.53 No.9 1–18 (Sep. 2012)

表 1

実行履歴の例 (Linux)

Table 1 Examples of Program Execution History (Linux).
1

SSH サービスからログインして実行されている bash プロセス/sbin/init /etc/rc.d/init.d/sshd /usr/sbin/sshd /usr/sbin/sshd /bin/bash

2コンソールからログインし得られた bash プロセス/sbin/init /sbin/agetty /bin/login /bin/bash
3コンソールからログインし，管理者として作業するため su コマンドを実行して得られた bash プロセス/sbin/init /sbin/agetty /bin/login /bin/bash /bin/su /bin/bashている．したがって，アプリケーションの処理内容を完全に把握するためには，アプリケーション自身にそれを申告

4. Linux に対する提案方式の実装させるのが最上であるが，すべてのアプリケーションに適用できる基準や記述方法は現状存在していない．また，ア
プリケーションが乗っ取られる可能性を考えると，権限を減らすことには問題ないが，権限を増やす申告を認めることは新たなリスクとなる．仮にそれらの問題が解決できた
場合にも，既存のアプリケーションの修正が必要となる．
このような背景により，直接的な手法によって，アプリケー
ションの処理内容を判定することは困難であるが，間接的手法を用いることにより，一定の範囲でアプリケーションの修正を必要とすることなく，その処理内容を判定することが可能である．
アプリケーションには，処理内容に影響を与える要因が存在する．それらをアクセス許可を与える際の条件（パラメータ）として用いることができれば，不適切な要求を識別，拒否することができる．アプリケーションの処理内容に影響を与える要因について，いくつかの具体例を示す．

• コマンドライン引数（多くのアプリケーションはオプ
ション指定を受け付ける）• 環境変数（実行時に参照するコマンドサーチパス，プ
ロキシーサーバなど）• ユーザ入力（ユーザの指示により行う処理を分岐する）• 入力データ（データの内容を解析して結果を表示する）• 設定ファイル（多くのアプリケーションは独自の設定
ファイルを持ち，起動時に参照する）• ライブラリ（故意に違うライブラリを参照させる攻撃が存在する）• 時間• 実行しているユーザ（管理者の場合処理を行う等）• 特定の名前を持つファイルの有無や内容（/etc/nologin, .htaccess 等）
注目すべきことは，上記を含む情報はすでにカーネル内で管理されているので，MAC の処理の中でそれをパラメータとして参照することが可能である．本稿では，MAC の中でアプリケーションの処理内容に影響を与える情報をポ
リシーの中でアクセス可否の条件基準パラメータとして用いることを提案する．

本章では，アプリケーションの処理内容を考慮したア
クセス制御方式の実装について，TOMOYO Linux を例に説明する．TOMOYO Linux は Linux 上の MAC の実
装例，およびそれを推進するプロジェクトの名称である．

TOMOYO Linux の方式および機能の検討については，著者のうち原田と半田が行い，提案方式の Linux カーネルへの実装とポリシーエディタなど標準ツールのコーディングについては，半田が単独で行っている．TOMOYO Linuxは，提案方式の検討を受けて随時拡張が行われており，本論
文執筆時点における最新版であるバージョン 1.8.3 は本論文の内容に対応している．TOMOYO Linux のソースコー
ドについて，SourceForge.jp 上*4 で公開している．Linux
カーネルのバージョン 2.6.30 以降には，メインライン向けに作成された機能限定版の TOMOYO Linux が標準機能として含まれている．

4.1 アプリケーションの実行状況の取得
Linux カーネルは標準の状態では，実行するアプリケー
ションがどのような履歴を持つかを管理していない．各ア
プリケーションのプロセスは，自分をつくりだした親のプロセスの id を覚えているが，終了したプロセスの情報はカーネルから削除されるため，限られた範囲でしか親プロ
セスをたどることができない．
もし，すべてのアプリケーションのプロセスについて，共通の基点から自身のプロセスが生成されるにいたった履
歴を持たせ，それらをプロセスの終了後も保持することができれば，各アプリケーションの実行状況を一意に定めることが可能となる．

4.1.1 「プログラム実行履歴」概念の定義と実現方式
TOMOYO Linux では，アプリケーションの実行状況の取得を可能とするために，プログラム実行履歴の概念を実現した．プログラム実行履歴とは，各プロセスが作られるまでに実行されたアプリケーションのパス名と実行しているアプリケーションのプログラム名（パス名）を半角ス
ペース文字をセパレータとして並べたものである．先に見た表 1 の内容は，そのまま/bin/bash に関するプログラム*4

c 2012 Information Processing Society of Japan

http://tomoyo.sourceforge.jp/

5情報処理学会論文誌

Vol.53 No.9 1–18 (Sep. 2012)

実行履歴の例となっている．

じドメインに所属するとは限らない

Linux におけるアプリケーション実行の仕組みを利用す

TOMOYO Linux では，すべてのプロセスについて，プることにより，すべてのプロセスについてそのプログラム

ログラム実行履歴を記憶しておき，その属するドメインご実行履歴を持たせることができる．その方法について図をとにアクセス許可を定義し，それに基づきアクセス制御を用いて説明する．図 1 は，Linux でログインして得られた行う．図 2 は，Fedora 15 における TOMOYO Linux のポ/bin/bash から，/bin/date（日付の表示と設定を行うコ

リシーエディタの画面のコピーである．各行がそれぞれ異マンド）を実行して，その結果を待ちあわせる際に発行されなるドメインに対応しており，現在までに実行されたアプるシステムコール（アプリケーションがカーネル機能を呼リケーションのプログラム名が表示されている．行間のイび出すためのインタフェース）の内容を示している．Linux

ンデントはドメインの親子関係を示しており，同じインデなど UNIX の流れを汲む OS では，アプリケーションのントを持つドメインは共通のドメインのプロセスから生成実行について特徴的な手順により行う．まず，アプリケー

されたものであることを示す．

ションを実行しようとする（親となる）プロセスが fork()
システムコールにより自身の複製となるプロセスを生成

4.2 アプリケーションの処理内容の判定

し，複製されたプロセスは execve() システムコールを呼漏れなく強制的なアクセス制御はカーネルで行う必要が

び出すことによってその内容（プロセスイメージ）がアプある．カーネルはアプリケーションからの断片的な要求にリケーションのものに置き換わる．図 1 で，/bin/bash のついて，それらを処理するという分担であるため，アプリ

プロセスは fork() システムコールを発行し，その複製さケーションからの要求について，その意図や複数の要求のれたプロセスが execve() システムコールを発行すること関連性を判定することはできない．アプリケーションの意

により/bin/date が実行されている（/bin/date のプロセ

図や要求の関連性を知るのは，アプリケーションの作者でスが終了すると/bin/bash のプロセスに処理が戻る）．各あり，アプリケーションのプログラム自身である．仮にアプロセスの右側に表示されているのは，それぞれのプロセ

プリケーションからカーネルに対してその意図を伝えるよ

スのプログラム実行履歴である．その内容はプロセスの生うにしたとしても，アプリケーションが乗っ取られた場合

成時に親のプロセスから引き継がれ（複写され），execve()を考慮するとその申告を信用することはできない．また，を行う際に実行しようとするアプリケーションのプログラ

それを行うためには既存のプログラムの修正と再コンパイ

ム名を追加することにより更新できることがわかる．

ルが必要となるデメリットもある．しかし，すでにカーネ

4.1.2 ドメイン

ル内に存在する情報（カーネルが管理している情報）であTOMOYO Linux では，ドメインという単位でアクセス

れば，アプリケーションに申告させる必要がないため，既制御を行う．TOMOYO Linux におけるドメインについ存のプログラムの修正を必要とせず，またアプリケーショて述べる．ドメインは，先に述べたプログラム実行履歴

ンの乗っ取りによる影響を受けず信用することができる．

について，その基点を追加したものである．アプリケー

Linux カーネル内には，プロセスに関する情報，i ノード

ションが何も実行されていない状態である「カーネル自身（ファイルの実体）に関する情報，アプリケーション実行要（カーネルスレッド）」について，そのプログラム名を仮想

求に関する情報，ファイルに関する情報などが存在してお的に<kernel>と表記することにする．定義によりすべて

り，ポリシー言語の仕様で，それらの情報に対応する変数のドメインは必ず<kernel>で始まるので，<kernel>は共を定義し，ポリシー言語の構文で条件式として，カーネル

通の基点となる．基点を導入することにより，プログラム

内のパラメータをアクセス制御の条件として記述できるよ実行履歴の一部と全体の区別が可能となる．

うにした．

ドメインを指定することによりプログラム実行履歴の内容が一意に定まる．あるプロセスについて，そのプログラ

4.3 MAC の実装

ム実行履歴がドメインと一致するとき，プロセスはその漏れなく，回避できないアクセス制御を行うためには，ドメインに属していると呼ぶ．Linux で最初に作られるプ

リファレンスモニタ [18][19] を実装すれば良い．具体的にロセスである/sbin/init は，<kernel> /sbin/init のドは，システムコールの呼び出しを捕捉（フック）し，そのメインに属する．コンソールからログインして得られた要求可否の判断を行う．許可する場合には本来の処理を実/bin/bash の所属するドメインは，<kernel> /sbin/init

行するが，そうでない場合は要求を拒否し，呼出しもとに/sbin/agetty /bin/login /bin/bash となる．

エラーを返す．リファレンスモニタの実装はフックする関ドメインは以下の性質を持つ．

数の書き換えにより行うが，バージョン 2.6 以降の Linux• すべてのドメインは親となるドメインをただ一つ持つは，カーネルにおけるアクセス制御の処理内容を拡張する• すべてのプロセスはひとつのドメインに所属する

ためのフレームワークである Linux Security Modules[20]• 実行されているアプリケーションが同一であっても同（以下，LSM と略す）を備えている．LSM を用いると，直c 2012 Information Processing Society of Japan6

情報処理学会論文誌

Vol.53 No.9 1–18 (Sep. 2012)

図 1

プログラム実行履歴の定義

Fig. 1 Deﬁning Program Execution History.

図 2

ドメイン遷移の例 (Fedora 15)

Fig. 2 Domain Transition Example (Fedora 15).

c 2012 Information Processing Society of Japan7

情報処理学会論文誌

Vol.53 No.9 1–18 (Sep. 2012)

接システムコールの処理内容を書き換えることなく，それ

表 2

TOMOYO Linux で利用できるワイルドカードをフックし，定義した処理（ここではアクセス制御）を追

Table 2 TOMOYO Linux wild card patterns.

加することができる．LSM ではシステムコールフックの内

パターン

意味

容について，「モジュール（セキュリティサーバとも呼ぶ）」\*/ 以外の 0 回以上の繰り返しと呼ぶ単位で管理しているが，LSM の現在の仕様は複数の\@/ と . 以外の 0 回以上の繰り返しモジュールの併用を認めていない．TOMOYO Linux は，\?

/ 以外の 1 文字\$

1 桁以上の 10 進数\+

10 進数 1 桁

したものと，独自にシステムコールをフックするバージョ\X

1 桁以上の 16 進数ンを提供している．

\x

16 進数 1 桁\A

1 文字以上のアルファベット\a

アルファベット 1 文字\-

パス名を除外する演算子/\{dir\}/

1 回以上の dir/の繰り返し

他のモジュールとの併用を可能とするため，LSM を使用

4.4 ポリシー仕様
本節では，TOMOYO Linux を用いることにより，従来のアクセス制御方式では，記述することができなかった多様な条件を考慮したアクセス制御が行えることを具体的なポリシー例により示す．TOMOYO Linux は，ファイルの4.4.1 ドメインポリシーの例

他にネットワークやシグナル送信などのアクセス制御に対TOMOYO Linux で，コンソールからログインしたユー応しているが，紙面の都合によりファイルに関するアクセ

ザが自分のパスワードの変更を行うために必要なポリ

ス許可についてのみ説明する．

シーについて例を示す．この例では，まずコンソール
任意条

からログインして実行しているシェルのプロセスのドメ件」という構成を持つ．「カテゴリ」はアクセス制御の分類

アクセス許可は，「カテゴリイン（<kernel> /sbin/init /sbin/agetty /bin/login

であり，ファイルに関するアクセス許可のカテゴリは file/bin/bash) において，/usr/bin/passwd（パスワードのである．「カテゴリ

操作

操作

必須条件

必須条件」は必須で，「操作」

変更を行うコマンド）のアプリケーションの実行を許可す

は客体に対して行おうとしている操作で，ファイルについる．この結果実行される/usr/bin/passwd のプロセスは，ては rename, execute などがある．「必須条件」は操作の新たなドメイン（<kernel> /sbin/init /sbin/agetty

対象となるファイルのパス名などである．パス名について/bin/login /bin/bash /usr/bin/passwd）において実は，/tmp 配下にプロセス ID を含む名前で作られる一時

行されるので，そのドメインに対して，/usr/bin/passwd

ファイルなど，名前が事前に決まらないものがある．また，が要求された処理を行うために必要なアクセス許可を定義

Web コンテンツなど，特定のディレクトリ配下のすべてのしなければならない．

ファイルを列挙せずまとめて許可したい場合がある．それ

TOMOYO Linux のポリシーは，ドメインごとの定義ブらの場合について，TOMOYO Linux ではワイルドカード

ロックが複数連続する構造を持ち，各ドメインのブロックを用いることで対応している．表 2 に，TOMOYO Linuxは，ドメイン名の宣言で始まり，そのドメインに許可するで利用できるワイルドカードの一覧を示す．

アクセス許可を必要なだけ列挙したものとなる．

「条件」については，必須条件と任意条件の 2 種が存在

図 3 の 1 行目は，この後に続くアクセス許可定義の内容する．必須条件は，「操作」の内容に対応して必ず指定しなが，/sbin/init から実行された/sbin/agetty から実行さければならないもので，必要となる条件の内容は「操作」

れた/bin/login から実行されたプログラム実行履歴を持ごとに異なる．たとえば file rename を許可するためにつ/bin/bash に関するものであることを示している．これは，必ず「リネーム前の名前」と「リネーム後の名前」を

は，コンソールからログインしたシェルで passwd コマン

指定しなければならず，その 2 つは必須条件である．

ドのアクセス許可定義を意味する．3 行目は，シンボリック

任意条件は，必要に応じてアクセスを許可する条件をよ

リンクを解決した後のパス名が/usr/bin/passwd である

り厳しく指定するために用いるもので，すべてのアクセス

アプリケーションについて，呼び出し名（exec.argv[0]）許可に対して，任意の数の任意条件を指定することがでが passwd であることを条件に，その実行を許可している．

きる．

もし，特定の引数を指定した場合だけ実行を許可したい場

以上 TOMOYO Linux ポリシーの概要について説明し合には，exec.argv[] として，すべての要素を条件としてた．ポリシー仕様の詳細については，プロジェクトの Web

追加すれば良い．引数の個数を用いて制限したい場合にページ*5 で公開している．

は，exec.argc=1 のように記述する．

TOMOYO Linux は，ホワイトリスト方式（陽に許可し*5

http://tomoyo.sourceforge.jp/1.8/
policy-specification/index.html

c 2012 Information Processing Society of Japanたもの以外はすべて拒否）を採用しているので，この定義ではコンソールからログインしたシェルから実行できるの

8情報処理学会論文誌

1Vol.53 No.9 1–18 (Sep. 2012)<kernel> /sbin/init /sbin/agetty /bin/login /bin/bash

2
3

file execute /usr/bin/passwd exec.realpath="/usr/bin/passwd" exec.argv[0]="passwd"

4

file read/write /dev/tty

5

file read /etc/passwd

6

file read /etc/profile

7

file read /home/harada/.bash_profile

8

file read /home/harada/.bashrc

9file read /etc/bashrc

10

file write /dev/null
図 3/bin/bash ドメインのポリシー（抜粋）Fig. 3 Policy of /bin/bash Domain.

は，ここに書かれた条件を満たす/usr/bin/passwd のみ( ii ) 任意条件付きアクセス許可の例

で，他のアプリケーションを実行しようとするとエラーと任意条件については，「属性=値」（属性が指定した値でなる．4 行目から 10 行目までは，このドメインに属するある場合は許可），あるいは「属性!=値」（属性が指定した/bin/bash が読み書きできるファイルについて許可して値でない場合は許可）の形式で条件式を記述する．条件式

いる．

は複数記述することが可能で，その場合すべての条件式が

図 4 は，図 3 で実行を許可された/usr/bin/passwd，すなわち「/sbin/init から実行された/sbin/agetty から実行された/bin/login から実行された/bin/bash から実行された」プログラム実行履歴を持つ/usr/bin/passwd に成立した場合のみアクセスが許可される．任意条件付きアクセス許可の利用例について示す．

• file symlink /dev/cdrom symlink.target="hdc"
シンボリックリンクの内容が hdc の場合のみ，/dev/cdrom

ついてのアクセス許可定義となる．passwd コマンドは，というシンボリックリンクの作成を許可する．

/etc/shadow の内容を読み込み，パスワードの内容を変更• file execute /bin/bash task.uid=500-1000

した結果を/etc/nshadow というファイルに書き込んでか

ユーザ ID の範囲が 500 から 1000 の場合のみ/bin/bash

ら，/etc/shadow にリネームを行っている．7 行目，9 行の実行を許可する．

目，10 行目では，単に対象（客体）となるファイル名だけで• file read /tmp/file001.tmp task.uid=path1.uid

なく，そのパーミッションやユーザ ID，グループ ID など

カレントプロセスのユーザ ID が/tmp/file001.tmp の所も必須条件として指定されており，これらと合致しない場

有者 ID と一致する場合だけそのファイルの参照を許可

合にはアクセス要求は拒否される．ラベルに基づく MACする．

は，パス名やモードなどを扱わないので，このような条件• file execute /usr/bin/ssh exec.realpath="/usr/bin/ssh"を付与することはできない．

exec.argv[0]="ssh"4.4.2 条件付きアクセス許可の例

呼 び 出 さ れ た 名 前 が ssh で ，シ ン ボ リ ッ ク リ ン ク を条件付きアクセス許可について，必須条件のみのアクセス許可と任意条件を含むアクセス許可について，利用例を示す．

( i ) 必須条件のみのアクセス許可の例
必須条件のみアクセス許可の利用例について示す．

• file rename /etc/mtab.tmp /etc/mtab

解 決 し た 結 果 の パ ス 名 が/usr/bin/ssh で あ る 場 合 に/usr/bin/ssh の実行を許可する．
• file execute /bin/bash exec.realpath="/bin/bash"
exec.argv[0]="-bash"
task.uid!=0 task.euid!=0
呼び出された名前が-bash（ログインシェル）で，シンボ/etc/mtab.tmp というパス名を/etc/mtab というパス名

リックリンクを解決した結果のパス名が/bin/bash で，にリネームすることを許可する．

かつプロセスのユーザ ID および実効ユーザ ID が 0（root• file create /var/lock/subsys/crond 0644

ユーザ）ではない場合に/bin/bash の実行を許可する．

/var/lock/subsys/crond の作成をパーミッション値が0644 の場合のみ許可する．
• file chmod /dev/mem 0644

4.5 ポリシーの運用
本節では，TOMOYO Linux を用いたアクセス制御を行/dev/mem のパーミッションについて 0644 にのみ設定すうために必要となるポリシーの策定および維持管理手順にることを許可する．

ついて述べる．

• file execute /bin/ls/bin/ls の実行を許可する．

c 2012 Information Processing Society of Japan

4.5.1 ポリシーの編集方法
システム起動時に，/etc/ccs/domain_policy.conf の9情報処理学会論文誌

1Vol.53 No.9 1–18 (Sep. 2012)<kernel> /sbin/init /sbin/agetty /bin/login /bin/bash /usr/bin/passwd

2
3

file read /etc/passwd

4

file read /etc/shadow

5

file write /etc/.pwd.lock6

file read /dev/urandom

7

file create /etc/nshadow 0666

8

file write /etc/nshadow

9

file chown/chgrp /etc/nshadow 0

10file chmod /etc/nshadow 00

11file rename /etc/nshadow /etc/shadow
図 4/usr/bin/passwd ドメインのポリシー（抜粋）Fig. 4 Policy of /usr/bin/passwd Domain.

内容が読み込まれる．このファイルは root ユーザを所有

表 3者とするファイルで，emacs などのテキストエディタを用

Table 3 TOMOYO Linux mode.

TOMOYO Linux の制御モード

モード

内容

動作

ス要求も TOMOYO Linux のポリシーに従い保護されるの

disabled

無効

通常のカーネルと同様に動作するで，「コンソールからログインして得られたシェルから実行

learning

学習

ポリシー違反が発生しても要求を拒否しない

いて編集することができる．このファイル自体へのアクセ

ポリシー違反が発生しないようにするのに必要なされた emacs のドメイン」のようにアクセスを許可するドアクセス許可をポリシーに追加する

メインを定義した上で，読み書き/参照のみなど操作のア

permissive

確認ポリシー違反が発生しても要求を拒否しない

クセス許可を必要に応じて条件を追加しながら定義する．

enforcing強制

ポリシー違反が発生したら要求を拒否する

TOMOYO Linux では，システム起動後のポリシーの調整を行うためのツールとして，CUI (Character User Inter-face) のポリシーエディタが提供されている．図 2 はポリ( i ) 一定期間 learning モードでシステムを稼働させる．こシーエディタの画面で，起動すると最初に現在のドメインれにより，プログラム実行履歴（ドメイン一覧）と各遷移が表示される．カーソル移動キーを用いてドメイン遷ドメインのアクセス要求の情報を収集する

移の内容を確認し，リターンキーを押下すると，選択されていたドメインのアクセス許可の一覧が表示され，追加と削除を行うことができる．ポリシーエディタにおける操作は即時にアクセス制御の内容に反映される．ポリシー編集用のツールには他にポリシーロードとセーブを行うツール( ii ) 前項で得られた結果を確認し，ポリシー定義を作成
する( iii )permissive モードでシステムを稼働し，アクセス許可に不足がないか確認する( iv )enforcing モードでシステムを稼働するが提供されている．TOMOYO Linux の管理用に提供され各工程に要する期間は，システムの内容と制限したい内ているツールの内容と利用方法については，プロジェクト

容により変わる．enforcing モードで稼働するタイミングの Web ページ*6 を参照されたい．

（ポリシーを凍結するタイミング）についての判断はシステ

4.5.2 ポリシー策定の流れ

ム管理者が行わなければならない．提案方式を用いると，

TOMOYO Linux のポリシー策定について，おおまかな必要とするアプリケーションを必要とする状況（ドメイン）

流れを述べる．より詳しい内容については，プロジェクトにて，実行することによって，実行履歴を得ることができが公開しているチュートリアル*7 を参照されたい．

る．その内容には，当該アプリケーションの中から呼び出

TOMOYO Linux には制御モードという概念がある．制されるアプリケーション群（およびさらにそれらから呼び

御モードは，アクセス制御の動作内容を指定するもので，出されるアプリケーション群）についても自動的に含まれdisabled, learning, permissive, enforcing の 4 種がある．各るので，現システムのあらゆる状況で関連するすべてのア

モードの意味について，表 3 に示す．

プリケーションを実行すれば，必要となる完全な実行履歴

モードは，ドメインごとに指定することができ，ポリを得ることができる．したがって，これを実行可能な場合

シーファイルで定義するか，あるいはポリシーエディタではそれでよい．しかし，一般にはこの組み合わせ数は膨大

変更することができる．TOMOYO Linux のポリシー策定

で，すべてを尽くすことは困難である．この問題は，一般の基本的な流れは以下のようになる．

に，システムのバグを取るために，あらゆるパターンの実行を行ってその結果をチェックすることが行われているこ*6*7

http://tomoyo.sourceforge.jp/1.8/man-pages/index.
html
http://tomoyo.sourceforge.jp/about.html

c 2012 Information Processing Society of Japanとと同様である．したがって，本提案システムもそれと同様，実用上は次のような考え方で実行漏れを防ぐのが適切

10情報処理学会論文誌

Vol.53 No.9 1–18 (Sep. 2012)と考えており，実際そのような運用を行っている．

• できるだけ長い時間をかけてプログラム実行履歴の情報を収集する観測する期間を長くすることにより，アプリケーショ
ンの実行漏れが起こる可能性を減らすことができる．
後述する Web サーバへの適用の実証実験では，約 2週間かけて行っている．

• 評価プログラム，テストツールなどがあれば利用する
アプリケーションごとに用意された評価プログラムや
テストツールがあれば，それらを実行することによって，網羅的にアプリケーションを実行させることができる．

• 試験を徹底する
ここでいう試験とは，ポリシーの試験ではなく，保護の対象とするコンピュータそのものであり，その上でサービスを提供するソフトウェアの試験のことである．

• バッチ処理，エラー処理について確認する
上の項目すべてを行ったとしても，月次バッチや，ディザスタリカバリなど，常時実行されないアプリケー
ションについて，漏れが生じる可能性がある．バッチ処理については，システムの時間を変えることにより，確認することができ，ディザスタリカバリ等について
は，それが発動する状況を人為的に起こすことにより確認する．
内容が固まったら，確認用の機能ではなく，保護用の機能によりシステムを起動する．

4.5.3 ポリシーの更新
制御モードを enforcing に切り替えることにより，TO-

MOYO Linux による保護が有効となる．システム管理者
は，ポリシーにないアクセス要求の有無と内容をログにより確認する．ログに残された要求の内容を確認した結果，該当する要求を許可すべきと判断したら，ポリシーエディ
タにより当該の内容を追加し，許可を与える．TOMOYOLinux のログの内容には，ドメイン名が含まれているため，
そのエラーが生じた状況を特定することが可能で，それを反映すべき箇所も明確である．

OS の ア ッ プ デ ー ト ，ア プ リ ケ ー シ ョ ン（ パ ッ ケ ージ）の追加や削除については，それによる影響が事前にわかる場合には，ポリシーエディタで修正，あるいは/etc/ccs/domain_policy.conf をテキストエディタで編集することにより対応することができる．そうでない場合については，一時的に MAC を無効にしてアップデートやインストール，削除を行ってからポリシーの修正を行う．
これは，TOMOYO Linux に限らず MAC 共通の運用である．ここで MAC を無効にするのは，MAC では管理者権限に関係なくアクセス要求を判定するため，アップデート
等が適用しないことが考えられるからである．

c 2012 Information Processing Society of Japan

5. 評価
本章では，提案方式の評価として，その特長について整
理し，使いやすさに関する初期検証の内容について述べる．
また，提案方式を導入したことによる処理遅延について，

TOMOYO Linux を用いて計測した結果について示す．
5.1 提案方式の特長
本研究の提案方式は以下の特長を持つ．

( i ) アプリケーションの処理内容を考慮したアクセス制御が行える
前章の例で示したように，アプリケーションの処理内容とアクセスを許可した後のシステムの状態を考慮したアクセス制御を行うことができる．

( ii ) システムの動作内容を理解して設定できる
MAC を導入したシステムでは，ポリシーにないアクセ
ス要求がないかを監視し，それが生じた場合，ポリシー定
義の漏れか，不正な要求が行われたかの切り分けを行い，その結果により対処を行う．提案方式では，アクセス要求がエラーとなった場合，そのプログラム実行履歴の情報が得られるので，状況の確認が容易である．

( iii )アプリケーション（ドメイン）ごとに独立にアクセス許可を定義できる
ラベルに基づく MAC の実装である SELinux では，情報システム全体を対象として，必要なラベルを定義する．ある
ラベルを持つアプリケーションでエラーが生じた場合，そのラベルを持つアプリケーション群と他のラベルとの遷移条件を考慮した上で対処を行うべきであるが，それは必ずしも容易ではない．4 章で示したポリシー例に見るように，
本アクセス制御方式のポリシーはドメインごとに独立にして定義され，修正できるので管理は容易である．

( iv )Role-Based Access Control としての使い方ができる
本稿で提案したアクセス制御方式は，Role-Based AccessControl Model[21] (RBAC) や Identity-Based Access Control Model 的な使い方も可能である．3 章のシェルのプログラム実行履歴の例を示したように，ログインシェルから/bin/su を実行して得られるシェルは，もとのシェルとは独立にアクセス許可を定義できる．/bin/su に限らずシェルをネストして起動しても同様であり，シェルの階層により与えるアクセス許可を変えることにより，シェルから実行されるアプリケーション単位で役割を持たせることも可能である．[22] ユーザ ID やグループ ID を条件として記述することにより，root（Linux/UNIX におけるシステム管理者アカウント）のみ，root 以外，特定のユーザ ID，グループ ID などアクセスを許可する条件を柔軟に記述することができる．

11

情報処理学会論文誌

Vol.53 No.9 1–18 (Sep. 2012)

5.2 使いやすさに関する初期検証
提案方式の運用について，ラベルに基づく MAC を採用思われる．実験参加メンバーによる報告書*9 *10 が公開されている．

している SELinux と机上での評価を行った．また，2007
年度，TOMOYO Linux について行った実証実験の結果に

5.3 性能への影響

ついて紹介する．

5.2.1 運用面での効果
独立行政法人情報処理推進機構では，被験者を用いた調

本節では，TOMOYO Linux を用いて，提案方式による性能への影響の測定結果について，システムコール種別による影響とポリシーの規模による影響について計測を行っ査の結果に基づき，SELinux を用いた「セキュアな Web

た結果について示し，考察を行う．

サーバ構築のガイドライン」[23] を公開している. 同ガイ

5.3.1 システムコール種別による影響

ドラインでは，SELinux の適用について，対象アプリケー

UNIX 系システム用のベンチマークツール，LMBench[24]ションの仕様調査と「標準セキュリティポリシー*8 定義のを用いてシステムコール種別による影響について計測を調査・解析・修正あるいは新規セキュリティポリシーの定行った．

義について，大きな作業工数が必要となると結論づけてい提案方式を適用した場合，性能による影響は原理的にはる．標準セキュリティポリシーが提供されていることは，

フックされるシステムコールが対象となり，フックされなシステム管理者にとって福音であるが，標準セキュリティ

いシステムコールは影響を受けないことが予想される．そポリシーが想定する環境とシステム管理者が管理するシ

こで，LMBench で計測できる OS 関連のシステムコール

ステムの環境は一致しない．標準セキュリティポリシーののうち，TOMOYO Linux がフックしないものと，フック

内容を管理対象のシステムに合わせるために，あるいはエするものについて分けて比較する．比較の条件についてラーが生じたときにその対処を検討する際に，システム管は，TOMOYO Linux をインストールしていない状態と，理者は膨大なポリシーの内容を理解しなければならなく

TOMOYO Linux によるアクセス制御を有効にした状態となる．

で，それぞれ LMBench を実行した．

提案方式では，アプリケーションの実行状況の分類はLMBench の実行環境について表 4 に示す．LMBench でカーネル内で自動的に行われ，また分類間の関係も容易にできる計測項目および詳細な仕様については，同ツールの理解できるので，システム管理者はそれぞれの実行状況

Web ページ*11 に掲載されているので，ここでは説明しな（ドメイン）ごとのアクセス許可定義に専念することがで

い．TOMOYO Linux がフックしていないシステムコール

きる．

を対象にした計測結果を表 5 に，TOMOYO Linux がフッ

5.2.2 実サーバへの導入評価クしているシステムコールを対象にした計測結果について，

2007 年度，NPO 日本ネットワークセキュリティ協会の表 6 に示す．なお，ベンチマークの実施にあたっては，ベセキュア OS 普及促進 WG（当時）では，セキュア OS 導入

ンチマークの実行に必要なプロセス以外が実行されていなの内容，効果，システム管理面の影響などを評価することをいようにした上で行った．表 5, 表 6 の読み方について説

目的に，同協会の Web サーバに TOMOYO Linux を導入

明する．列，Func. は LMBench のテスト項目，列，Base

する実証実験を行った．実験では，インターネットに公開

は TOMOYO Linux をインストールしていない状態の計されている Apache Web サーバを対象として，ファイルに

測結果 (µsec)，列，TOMOYO は TOMOYO Linux を導入

関するアクセス制御を設定した．Web サーバでは CGI をし，MAC を有効にした状態の計測結果 (µsec)，列，Diﬀ は使用していたが，CGI は Apache とは別のドメインとして

TOMOYO と Base の差分 (µsec)，列，Overhead は，管理され，ログにより収集されたファイルアクセスの要求

Overhead =の履歴から，それぞれのドメインに必要なアクセス許可をT OM OY O − Base
× 100
Base

ファイル単位で定義している．実験参加者は，TOMOYOにより得られた数値であり，Overhead の値が 100 であれば，Linux の動作原理，ポリシーの編集については，ごく短時

TOMOYO Linux を有効にしない場合に対して，100%の遅間で理解することができ，ポリシーの策定の作業を通じて，延が生じたこと，すなわち処理に要する時間が 2 倍になっLinux サーバの動作内容について把握することができたとたことを意味する．

いう感想がある．これらの効果は，ポリシーでパス名をそ

表 5 を見ると，TOMOYO Linux を有効にした場合ののまま記述できること，プログラム実行履歴によるアクセ

遅延の割合は，±5%の範囲に収まっている．理論上，TO-

ス制御の分類が管理者にとって理解しやすいことによると

MOYO Linux を有効にすることにより処理速度が向上す
ることはないため，これらは，LMBench による計測の誤*9

http://www.jnsa.org/result/2007/tech/secos/
ポリシーの抜粋も収録されているがバージョンの相違により本稿の例とは異なっている．
*11 http://www.bitmover.com/lmbench/*10*8

前述のディストリビューションの標準設定に合わせたポリシーのこと．

c 2012 Information Processing Society of Japan12

情報処理学会論文誌

Vol.53 No.9 1–18 (Sep. 2012)

表 5

LMBench の結果（フック対象外のシステムコール分）
Table 5 Result of LMBench (not hooked).

Func.

Base (µsec)

TOMOYO (µsec)

Diﬀ (µsec)

Overhead (%)

null syscall

0.274

0.269

0.0

-1.82

null I/O

0.4365

0.418

0.0

-4.24

Select on 100 tcp fd’s

7.08157.14550.1

0.90

Signal handler installation

0.552

0.56

0.0

1.45

2p/0K ctxsw

10.97

10.665

-0.3

-2.78

2p/16K ctxsw

11.26

11.07

-0.2

-1.69

2p/64K ctxsw

14.21

14.39

0.2

1.27

8p/16K ctxsw

12.22

11.755

-0.5

-3.81

8p/64K ctxsw

14.03514.0950.1

0.43

16p/16K ctxsw

12.185

12.04

-0.1

-1.19

16p/64K ctxsw

14.13514.225

0.1

0.64

Pipe

38.3

36.73

-1.6

-4.10

AF UNIX

24.47

24.28

-0.2

-0.78

Mmap

2341.55

2375.133.5

1.43

Page Fault

2.528292.58089

0.1

2.08

3.254

3.35045

0.1

2.96

Select on 100 fd’s

表 6

LMBench の結果（フック対象のシステムコール分）

Table 6 Result of LMBench (hooked by TOMOYO).
Func.

Base (µsec)

TOMOYO (µsec)

Diﬀ (µsec)

Overhead (%)

Simple stat

3.12

7.11454.0

128.03

Simple open/close

5.037

9.50654.5

88.73

Signal handler overhead

3.8015

5.961

2.2

56.81

Process fork+exit

300.35

301.7

1.3

0.45

Process fork+execve

1001.95

1062.55

60.6

6.05

Process fork+/bin/sh -c

2226.1

2551.2

325.1

14.60

UDP

54.65

69.91

15.3

27.92

RPC/UDP61.56580.615

19.1

30.94

TCP

58.04

57.3

-0.7

-1.27

RPC/TCP

72.64

71.36

-1.3

-1.76

TCP/IP connection cost

65.8

72.4

6.6

10.03

0K File Create

25.32

41.035

15.7

62.07

0K File Delete

19.86527.795

7.9

39.92

10K File Create

80.9

95.855

15.0

18.49

10K File Delete

41.075

50.33

9.3

22.53

c 2012 Information Processing Society of Japan13

情報処理学会論文誌

表 4

Vol.53 No.9 1–18 (Sep. 2012)

ベンチマークに用いた環境

Table 4 Benchmark Envrionment.
speciﬁcation/version• アクセス許可数増加によるアクセス許可探索時間の増大
ドメイン探索時間の増大については，指定した数値だけ

CPU

Core 2 Duo T7200 2.0GHz

ドメインを機械的に生成するプログラムを作成し，ドメ

Memory2GBOS

Ubuntu 10.04 x86 64

イン数が 2 から 100000 までの範囲について/tmp/reexec

Kernel

2.6.32-39.86

TOMOYO Linux

1.8.3p5

行した場合の処理時間について計測した．各ケースについBenchmark tool

LMBench 3.0-a9て，/tmp/reexec のためのドメインは最後に見つかるよう（自分自身を指定された回数，実行するプログラム）を実にしている．ドメイン数と処理時間の関係について，図 5差であると考えられる．

に示す（ドメイン数は対数軸を用いている）．

表 6 を見ると，stat, open/close, signal handler に
0.4

ついて，50%以上の遅延が生じている．0K File Create"bench1.dat"
0.35（空のファイルの作成）について，60%以上の遅延となってて値が小さくなっている．後者は空のファイルを作成した
後で，10KB のデータの write を行っており，TOMOYO
ではフックしていない処理が加わることによって，遅延時

0.3
delay (microseconds)

いるが，10K File Create については，18.49%とかえっ

0.25
0.2
0.15
0.1
0.05

間の相対的な割合が小さくなった結果このように見えると

0
1

10

考えられる．
プログラム実行履歴の処理の影響を受けると考えられる

fork 関連の項目については，fork と exec の組み合わせ

図 5

100
1000
number of domains (logscale)

10000

100000

ドメイン数増加による処理速度の遅延

Fig. 5 Performace delay due to domain number increase.

で 5%程度の遅延が生じている．fork+/bin/sh -c について，値が大きくなっているのは，/bin/sh の exec が行わ

ドメイン数が 2 の場合について，TOMOYO Linux が有れることにより，exec の処理が 2 度実行されるためと考効な場合と，TOMOYO Linux がインストールされていなえられる．

い場合の差は，0.00362µsec だった．図 5 では，ドメイン

LSM を用いて，MAC（セキュア OS）の性能評価を行う

数について対数軸を用いているが，予想どおりドメイン数試みとして，LSM Performance Monitor (LSMPMON)[25]の増加に伴いドメイン探索に要する時間の遅延が増大し，がある．LSMPMON を用いるとフック関数の呼び出し回

ドメイン数が 10000 を超えると増加の割合が顕著となって数と処理時間を記録できるが，ユーザやシステム管理者がいることがわかる．

体感する性能への影響の予測という点では，課題が解決さ

アクセス許可探索時間の遅延については，指定した数値

れておらず，今後の研究が期待される．

だけアクセス許可を機械的に生成するプログラムを作成し，5.3.2 ポリシーの規模による影響

1 から 100000 までの範囲について，/dev/null を 10000 回

パッケージのインストールなどにより，実行されるアプ

open する時間を計測した．各ケースについて/dev/null

リケーションの数が増加し，ポリシー定義が増大することの open を許可するエントリは最後に見つかるようにしていによる性能への影響について評価を行った．

る．アクセス許可の行数と処理時間の関係について，図 6提案方式では，アプリケーションの実行（execve システに示す．アクセス許可の行数は対数軸を用いている．アクムコール実行時）にそのプロセスに対応するドメインを割

セス許可数が 1 の場合について，TOMOYO Linux が有効

り当てる．次に，要求された内容が，当該ドメイン内のアな場合と，TOMOYO Linux がインストールされていない

クセス許可の内容に含まれているかどうかを判定を行う．

場合の差は，0.0032µsec だった．

実行されるアプリケーション数が増加し，ドメイン数が増

図 6 では，アクセス許可数について対数軸を用いている

加することにより，アクセス要求ごとに該当するドメイン

が，予想どおりアクセス許可数の増加に伴いアクセス許可を探すための処理時間が増加する．また，アプリケーショの探索に要する時間が増大し，アクセス許可数が 10000 をンの処理内容が複雑化することにより，ドメインごとのア超えると増加の割合が顕著となっていることがわかる．

クセス許可数が増加し，該当するアクセス許可を探すため2005 年に最初のバージョンを公開してから現在までのの処理時間が増加する．したがって，ポリシーの規模が増経験則として，主要な Linux ディストリビューションに大することによる性能への影響について，次の 2 つにより

TOMOYO Linux を導入して利用する場合，ドメイン数お影響を計測することができる．

よびドメイン内のアクセス許可数について，それぞれ 2000

• ドメイン増加によるドメイン探索時間の増大

c 2012 Information Processing Society of Japan

未満の範囲に収まることが確認されている．パッケージの14情報処理学会論文誌

Vol.53 No.9 1–18 (Sep. 2012)

イルから得られた情報が漏えいしないことが重要であっ

1.6"bench2.dat"

た．ラベルに基づく MAC は，このニーズを満たしている

delay (microseconds)

1.4
1.2

が，アプリケーションの処理の内容には関心が払われてい1
0.8

なかった．提案方式は，個々のアプリケーションのプロセ

0.6

スが行う処理の内容に注目し，必要とする処理以外を行わ

0.4

せないことを目指している．提案方式は，ラベルに基づく

0.2

アクセス制御方式の代替ではなく，その限界を補完するも

0
1

10

100
1000
10000
number of acl definitions (logscale)

100000

図 6 ドメイン内アクセス許可数増加による処理速度の遅延

Fig. 6 Performace delay due to ACL number increase.

のと位置づけることができる．

6.1.2 AppArmor との比較
TOMOYO Linux は 2005 年 11 月に，AppArmor は 2006
年 1 月に公開された．公開されるまでお互いにパス名に基追加を行い，実行するアプリケーションの数が増えること

づく MAC を開発していることを知らなかったため，同じによって，ドメイン数は増加するが，図 5 および図 6 の結

パス名方式でありながら異なる実装方式となっている．

果を見ると，通常の利用においては，性能上大きな支障は( i ) 実装面での違い
TOMOYO Linux は，AppArmor よりも先に，様々な要生じないと考えられる．

6. 考察因（コマンドライン引数や環境変数などの条件パラメータ）を考慮したアクセス可否判断の必要性に気付き，実際に実装

本章では，提案方式に対する考察として，関連性の高いを行い，既にメインラインに採用されている．AppArmor

他の方式との比較を行い，典型的な不正アクセス手法に対でも，どのような条件（パラメータ）をチェックすべきする効果について確認する．さらに，提案方式では解決でかの議論が始まり，2011 年の 11 月，AppArmor 開発者のきないケースと，その対策として，機能を強化する際の課

メーリングリストにアクセス制御の際に環境変数の値を用

題について述べる．

いることが提案*12 された．メーリングリストの議論では，

TOMOYO Linux における仕様や実装方法について紹介さ
6.1 他の方式との比較

れ，今後 AppArmor においても採用される可能性がある．

6.1.1 ラベルに基づく MAC との比較

( ii ) 提案方式の適用可能性
AppArmor と TOMOYO Linux は，客体についてパス( i ) ラベルに基づく MAC の特長と適した用途
ラベルに基づく MAC では，主体と客体について，リネー

名を用いる点において共通しているが，主体の分類についムなど名前の変更に左右されることなく，アクセス可否判て実装方式が大きく異なり，同一の方式と見なすことは適断を行うことができる，また，名前を用いないので，名前を当ではない．具体的には，TOMOYO Linux では，起動時持たない資源にも適用することができる．これらのことかからのすべての履歴を記録してその内容に基づいてポリら，ラベルに基づく MAC は，主体から客体へのアクセス

シーを定義できるので，起動時からシャットダウンまでの可否を堅固に制限するという用途に適したものと言える．

すべてのプロセスを対象としたアクセス制限が実現可能で( ii ) 提案方式の特長と適した用途ある．AppArmor では，起動時からの履歴は記憶していな

提案方式では，アプリケーションの処理内容に影響を与いので，デーモンや Web ブラウザなど特定のプロセスをえる要因をアクセス可否判断のパラメータとして活用す対象としたアクセス制御しか実現できない．これは，設計ることにより，アクセスを許可する場合を絞り込んでいく思想の違いに由来する差異である．

ことができる．パラメータとして，ファイル名や DAC の( iii )AppArmor にない TOMOYO Linux の工夫点
AppArmor にない TOMOYO Linux の工夫点について，

パーミッションなどを用いることができるので，それらの変更をシステム管理者が認めた範囲内に収めることができる．このことから，提案方式は，情報システムの状態を正しく維持し，余計な機能を利用させないという用途に適したものと言える．

( iii )提案方式の位置付け

以下に示す．

• システムの起動時からシャットダウンまでのすべてのプ
ロセスを対象としたアクセス制限が可能である．

• ドメイン遷移がツリー構造になることを応用することで，RBAC 的な使い方やログイン認証の強化も可能である．

どのような方式が適しているかは，どのような脅威を防• ワイルドカードとして解釈する文字を \（バックスラッ

ぎたいかにより決まる．TCSEC が発表された 1983 年のシュ）でエスケープするという方式であるため，互換性

時点では，機密情報の漏えいが主な関心事であり，防ぎたを維持しながらワイルドカードの種類を増やすことがでい脅威であった．資格を持つアプリケーションだけが，それらが必要なファイルにアクセスできること，およびファc 2012 Information Processing Society of Japan*12

https://lists.ubuntu.com/archives/apparmor/
2011-November/001668.html

15

情報処理学会論文誌

Vol.53 No.9 1–18 (Sep. 2012)

きる．

ここで不正とは，システム管理者が望まないアプリケー• .git のように特定の意味を持つディレクトリ名やファションの実行を指す．典型的な例としては，ネットワーク

イル名を除外するために，\-という減算演算子を備えてを介してサービスを提供しているサーバの脆弱性を突いている．

これを乗っ取り，シェルを実行する場合（およびそのシェ• できあいのポリシーを用いないため，対象となるシステ

ルから実行するアプリケーション）がこれにあたる．バッ

ム向けに無駄（不要なアクセス許可）の無いポリシーを定ファオーバーフロー攻撃，書式文字列攻撃，OS コマンド

義することができる．そして，自分で内容を理解して設

インジェクション攻撃なども同様である．バッファオー

定しているため，問題が起きたときでも無効にしてしま

バーフロー攻撃では，シェルを起動してから不正操作を行うことが無い．

うのが一般的である．対象となるアプリケーションについ6.1.3 Context-aware Access Control 取り組みとのて，/bin/sh の実行を許可しなければ，脆弱性を持ってい比較

るアプリケーションが奪われたとしてもシェルの起動に失

近年, コンテキストを反映したアクセス制御 (CAAC:

敗し，それ以降の操作を許さないようにすることができる．

Context-aware Access Control) に関する取り組みが活発

ラベルに基づく MAC でこれを行うには，主体の状況とそに行われている.

の遷移，各状況に置かれた主体に対する客体の組み合わせ

Matthias Baldauf らの “A survey on context-aware sys-

により主体および客体のラベル定義が必要となる．本研究tems”[26] では，Context-aware system について，「ユーザの提案方式では，各プロセスについてその置かれた状況をの積極的な介在を必要とせずに環境的なコンテキストを考示すプログラム実行履歴を持つため，管理者が新たにそれ慮することにより，ユーザビリティや効率を向上することを定義する必要はない．また，本来の処理としてシェルのを目指すもの」と定義している．今日 CAAC に関連する実行が必要となる場合には，方式を問わずその実行を許可

取り組みとしては，モバイルやユビキタスの領域で，位置しなければならないが，提案方式を用いればコマンドライ

情報やネットワーク情報を context と扱うものおよび Web

ン引数，環境変数などをアプリケーション実行の制約条件

サービスに context の概念を導入する試みなどが多い [27]．

として限定することができるので，悪用されるリスクを軽CAAC における context は抽象的な概念であり，利用でき減できる．

る情報を集めて活用することにより付加価値を目指すと理( ii ) パス・トラバーサル攻撃

解すれば，本論文で提案方式も CAAC に関連すると分類できる．

相対パスなどを利用し，本来アプリケーションがアクセスする必要のないファイルの読み書きを行う攻撃がある．

CAAC に関する取り組みで，本論文の提案に近いものと本稿で提案する方式について Linux 上に実装する場合にして，Salvia[28] がある．Salvia では，コンテキストを内部

は，プログラム実行履歴やパス名について，それらのカーと外部の 2 種に分けて，内部コンテキストとしては OS 内

ネル内におけるデータ講造に変換したものから絶対パス名

部で取得可能なプロセスの属性値とシステムコールの履歴を逆算し，そのパス名を用いていることによって，パス・を，外部コンテキストとしては位置情報，絶対時刻，無線

トラバーサル攻撃を無効とすることができる．

LAN アクセスポイント (ESSID) などを用いるプロトタイ( iii )シンボリックリンク攻撃

プを構築している．内部コンテキストとしてプロセスの属

シンボリックリンクは，対象となるファイル（パス名）

性値を利用するという点については，本論文におけるアプに対して，異なるファイルであるかのように見せる効果をリケーションの処理内容の判定の考え方に，システムコー持つ．これを悪用することにより，アプリケーションにリルの履歴はプロセスの状態の細分化を目指しているという

ンク先のファイルを破壊させる攻撃をシンボリック攻撃と点で，目指しているところは本論文の提案に近いと言える．

呼ぶ．本稿で提案する方式を用いる場合，まず攻撃に用い

しかし，システムコールについてシステムコール番号，引られるディレクトリにシンボリックの作成が許可されてい数，返り値をもってそのプロセスが実行される状況を推測なければ攻撃が成立しない．もし，許可されていた場合でするには，詳細な分析が必要となる．特定の場合のみを抽もさらに作成しようとするシンボリックのリンク先（ファ出することは可能でも，全面的に利用することは困難と考

イル名やディレクトリ名の文字列）を制約条件として限定えられる．提案方式では，内部的コンテキストとしてドメすることができるので，悪用されるリスクを軽減できる．

インを用いることで，より簡便に実現できる利点がある．

6.3 機能強化に向けた課題
6.2 不正アクセス手法に対する効果
提案方式について，典型的な不正アクセス（攻撃）の手

提案方式は，アプリケーション実行要求（execve()）を契機として，アクセス主体ごとのプログラム実行履歴を導法 [29] への効果について評価する．

出し，主体の実行状況を分類する．そのため，execve() を( i ) 不正なアプリケーションの実行

伴わない限り，アクセス主体の実行状況を分離することがc 2012 Information Processing Society of Japan16

情報処理学会論文誌

Vol.53 No.9 1–18 (Sep. 2012)

できない問題がある．

性能への影響の度合いについて，TOMOYO Linux を用い

例えば，Web サーバの Apache は，CGI (Common Gate-

た計測結果を用いて，影響の内容と程度についての考察を

way Interface) をサポートしており，一般的に利用されてい示した．今後は，アプリケーションからの申告の併用によるが，提案方式では，CGI の実行方法が execve() を伴う場

る，アプリケーション実行状況の精度の向上や，使いやす

合には，その CGI は独立したドメインとなるが，mod_perl

さに関する検証方法の検討などを行う予定である．

のように execve() を伴わない場合には，Apache と同じド

謝辞 査読者の方々より多数の貴重なご助言をいただきメインになってしまう．これについては，アプリケーショ

ました．感謝いたします．本研究の論文化について，情報

ンが，新たにドメインを分けたいという情報を伝える仕組

セキュリティ大学院大学，板倉征男教授（当時．後に同大みを実現すれば，execve() を伴わない CGI についても，

学名誉教授．2011 年 8 月ご逝去）から懇切なるご指導を独立なドメインとして扱うことができるようになる．

いただきました．板倉先生にご指導いただくことがなけれ提案方式は，アプリケーションの修正を必要とせずに，ば，本論文が世に出ることはありませんでした．ここにあ任意のアプリケーションに適用できる利点を持つが，アプ

らためて先生への感謝を記し，心からご冥福をお祈りいた

リケーション自体の申告を併用することにより，アプリ

します．

ケーションの作者がより直接，具体的に不要なアクセス要
求を排除することが可能となる．この申告方式を実現する

参考文献

ことが，今後の課題である．

[1]

また，別の問題としては，例えば，共有ディレクトリに置かれた一時ファイルについて，それらを作成したアプリ[2]ケーションに限定してアクセスを許可するような場合には，それぞれのファイルについて，その所有者に関する情報を覚えさせておき，それに基づいたアクセス制御を行う必[3]要がある．そのような場合は，提案方式をラベルに基づく

MAC と併用することにより課題を実現することができる．

[4]

その他にも，仮想化されたサーバを実行するアプリケー
ションについて，同じプログラム実行履歴を持つアプリ
ケーションは，実行している内容が異なる仮想マシンで[5]あってもアクセス制御の許可内容を区別することができな
い．仮想マシンごとにアクセスできる範囲を制限し，互いに影響を及ぼさないようそれらのケースへ適用する方法も今後の課題である．

[6]

7. おわりに[7]

本稿では，従来のアクセス制御では考慮されていなかったアプリケーションの処理内容に注目するアクセス制御方式を提案し，それを実現するための方法について，筆者らが Linux 上に実装した TOMOYO Linux を例にあげて示した．提案方式では，アプリケーションの実行状況ごとに，各アプリケーションが行おうとする処理を考慮したアクセ

[8]
[9]
[10]

ス制御を可能とする．それにより，従来のアクセス制御方式では識別できなかった不正，不要なアクセス要求を拒否
し，情報セキュリティを高めることができる．提案方式の有効性と応用可能性について，TOMOYO Linux ポリシー

[11]の例により示し，提案方式を実装した情報システムの使いやすさについて，ラベルに基づく MAC との机上比較，お[12]

よび TOMOYO Linux の実証実験の結果について紹介し[13]た．また，典型的な不正アクセス手法に対する効果について考察を行い，提案方式が典型的な攻撃手法に対して有効[14]

原田季栄，半田哲夫，板倉征男：TOMOYO Linux の設計と実装，コンピュータシステム・シンポジウム論文集，
pp. 101–110 (2009).
原田季栄，半田哲夫：Linux のセキュリティ機能 : 4．ラベルに基づくセキュリティの限界とその補完 TOMOYOLinux の設計思想と試み，情報処理， Vol. 51, No. 10, pp.
1276–1283 (2010).
Peterson, D. S., Bishop, M. and Pandey, R.: Flexible
Containment Mechanism for Executing Untrsted Code,11th USENIX Security Symposium, pp. 207–225 (2002).
大山恵弘：ネイティブコードのためのサンドボックスの技術，コンピュータソフトウェア，Vol. 20, No. 4, pp.
55–72 (2003).
Goldberg, I., Wagner, D., Thomas, R. and Brewer, E.:
A secure environment for untrusted helper applications
conﬁning the Wily Hacker, Proceedings of the 6th conference on USENIX Security Symposium, Focusing on
Applications of Cryptography-Volume 6, USENIX Association, pp. 1–1 (1996).
Barth, A., Jackson, C., Reis, C. and Team, T.: The security architecture of the Chromium browser (2008).
Loscocco, P. A., Smalley, S. D., Muckerbauer, P. A., Taylor, R. C., Turner, S. J. and Farrell, J. F.: The Inevitability of Failure: The Flawed Assumption of Security inModern Computing Environments, 21st National Information Systems Security Conference, Vol. 10, No. 2, pp.
303–314 (1989).
Bishop, M.: Computer Security: Art and Science. 2003.
Tcsec, D.: Trusted computer system evaluation criteria,
DoD 5200.28-STD, Vol. 83 (1983).
Peter Loscocco, N.: Integrating ﬂexible support for security policies into the Linux operating system, Proceedingsof the FREENIX Track 2001 USENIX annual technicalconference, June 25-30, 2001, Boston, Massachusetts,
USA, Citeseer, p. 29 (2001).
Loscocco, P. A. and Smalley, S. D.: Meeting Critical Security Objectives with Security-Enhanced Linux, Ottawa
Linux Symposium (2001).
Smalley, S.: Conﬁguring the SELinux policy, NAI Laboratories (2005).
Schauﬂer, C.: Smack in embedded computing, Proceedings of the 10th Linux Symposium (2008).
Cowan, C., Beattie, S., Kroah-Hartman, G., Pu, C., Wagle, P. and Gligor, V.: Subdomain: Parsimonious server

であり，方式に起因する重要な弱点がないことを確認した．

c 2012 Information Processing Society of Japan17

情報処理学会論文誌

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

Vol.53 No.9 1–18 (Sep. 2012)

security, Proceedings of the 14th USENIX conference on
System administration, USENIX Association, pp. 355–
368 (2000).
Winter, J.: Trusted computing building blocks for embedded linux-based ARM trustzone platforms, Proceedings of the 3rd ACM workshop on Scalable trusted computing, ACM, pp. 21–30 (2008).
Watson, R., Anderson, J., Laurie, B. and Kennaway, K.:
Capsicum: practical capabilities for UNIX, USENIX Security (2010).
Ken, W.:
Buﬀer Overﬂow Attacks and TheirCountermeasures., コ ン ピ ュ ー タ ソ フ ト ウ ェ ア ，Vol. 19, No. 1, pp. 49–63 (online), available fromhhttp://ci.nii.ac.jp/naid/110003744115/en/i (2002-0115).
Sandhu, R. and Samarati, P.: Access control: principle and practice, Communications Magazine, IEEE,
Vol. 32, No. 9, pp. 40–48 (1994).
榮樂恒太郎，新城 靖，板野肯三：システム・コールに対するラッパ/リファレンス・モニター SysGuard の設計と実現，情報処理学会論文誌，Vol. 43, No. 6, pp. 1690–1701(2002).
Wright, C., Cowan, C., Smalley, S., Morris, J. andKroah-Hartman, G.: Linux security modules: Generalsecurity support for the Linux kernel (2003).
Sandhu, R., Coyne, E., Feinstein, H. and Youman, C.:
Role-based access control models, Computer, Vol. 29,
No. 2, pp. 38–47 (1996).
原 田 季 栄 ，松 本 隆 明：セ キ ュ リ テ ィ 強 化 OS に よる ロ グ イ ン 認 証 の 強 化 手 法 ，静 岡 大 学 情 報 学 研
究 ，Vol. 11, pp. 93–102（ オ ン ラ イ ン ），入 手 先
hhttp://ci.nii.ac.jp/naid/110007117435/i (2005).
情報処理振興技術協会セキュリティセンター：ガイドラ
イン「セキュアなインターネットサーバの設定と運用」，
技術報告 (2003).
McVoy, L. and Staelin, C.: lmbench: Portable tools for
performance analysis, Proceedings of the 1996 annual
conference on USENIX Annual Technical Conference,
Usenix Association, pp. 23–23 (1996).
松田直人，佐藤和哉，田端利宏，宗藤誠治：LSM を利用したセキュア OS の性能評価機能の実現と評価，電子情報通信学会論文誌 D， Vol. J92-D, No. 7, pp. 963–974 (2009).
Baldauf, M., Dustdar, S. and Rosenberg, F.: A survey oncontext-aware systems, International Journal of Ad Hocand Ubiquitous Computing, Vol. 2, No. 4, pp. 263–277(2007).
Truong, H. and Dustdar, S.: A survey on context-aware
web service systems, International Journal of Web Information Systems, Vol. 5, No. 1, pp. 5–31 (2009).
KAZUHISA, S., YOSHIMI, I., KOICHI, M. and
EIJI, O.: An Adaptive Data Protection Method
based on Contexts of Data Access in PrivacyAware Operating System Salvia(Operating System),
情 報 処 理 学 会 論 文 誌. コ ン ピ ュ ー テ ィ ン グ シ
ス テ ム ，Vol. 47, No. 3, pp. 1–15 (online), available from hhttp://ci.nii.ac.jp/naid/110004708857/en/i(2006-03-15).
品川高廣：オペレーティングシステムによる不正アクセス防止技術，コンピュータソフトウェア， Vol. 21, No. 6,
pp. 482–493 (2004).

原田 季栄 （正会員）
1985 年，北海道大学工学部応用物理学
科工業数学講座卒業．同年日本電信電話（株）入社．2003 年より（株）NTT
データにて，オープンソースのプロ
ジェクトマネージメントに携わり，オ
ペレーティングシステムのセキュリ
ティ強化に興味を持つ．2012 年，情報セキュリティ大学院
大学情報セキュリティ研究科修了，博士（情報学）．情報処
理学会，電子情報通信学会，IEEE, ACM 各会員．

半田 哲夫
2001 年青山学院大学理工学部電気電子工学科卒業．同年 NTT データカス
タマサービス（株）入社．現在 NTT
データ先端技術（株）に勤務．2003 年
より Linux カーネル開発に従事，オペ
レーティングシステムのセキュリティ
強化に興味を持つ．

橋本 正樹 （正会員）2010 年 3 月，情報セキュリティ大学
院大学情報セキュリティ研究科修了，博士（情報学）．同年 4 月より情報セキュリティ大学院大学情報セキュリ
ティ研究科・助教．情報処理学会，電子情報通信学会，日本ソフトウェア科
学会，IEEE 各会員．電子情報通信学会 ISS・情報通信シ
ステムセキュリティ研究会専門委員．

田中 英彦 （正会員）
昭和 45 年東京大学大学院博士課程修了，工学博士．東京大学工学部教授、
同情報理工学系研究科教授・研究科長
を経て、平成 16 年情報セキュリティ大
学院大学教授，研究科長．平成 24 年
同大学学長．計算機アーキテクチャ，
分散処理，知識処理，デペンダブル情報システム等に興味を持つ．著書に「非ノイマンコンピュータ」「計算機アー
キテクチャ」「Parallel Inference Engine」などがある．情報処理学会名誉員、電子情報通信学会，人工知能学会, 各
フェロー, IEEE ライフフェロー．

c 2012 Information Processing Society of Japan

18