Comments
Description
Transcript
情報漏洩を防止する オペレーティング・システム
卒業論文
情報漏洩を防止する
オペレーティング・システム
平成 23 年 2 月 14 日 提出
指導教員
坂井修一 教授
五島正裕 准教授
工学部電子工学科
03-070080
小西 洋太郎
概要
コンピュータシステムが扱う情報は多様化しており，個人情報や企業の機密情報，商用マルチメ
ディアコンテンツなど，一般に保護されるべき情報が漏洩してしまう問題が多発している．イン
ターネットが発達した現在では，漏洩した情報は短期間に広く流通し，その回収も極めて困難であ
るため，情報漏洩の被害は甚大なものとなる．
コンピュータシステムから情報が漏洩する原因としては，ユーザの過失や悪意をはじめ，スパイ
ウェアやトロイの木馬といったマルウェアによるもの，脆弱性を抱えたプログラムに対する外部か
らの攻撃によるものなど，多岐に渡る．
従来の情報漏洩対策では，アクセス制御手法やディジタル著作権管理手法などが用いられてい
る．しかしこれらの手法は，実行されるアプリケーションがセキュリティ上安全であるという前提
に基づいて成立している．このため，外部からの攻撃などがあった際に，セキュリティが保たれる
保証はない．
アプリケーションの信頼性とは無関係に情報漏洩を防止する手法として，インフォメーションフ
ロー制御方式があるが，すべてのインフォメーションフローを完全に制御することは不可能であ
り，そうした手法を情報漏洩防止に応用する技術は実現されていない．
本論文では，アプリケーションの信頼性に依存しない情報漏洩防止を実現する OS を提案する．
これまで複数の権限が与えられていたプロセスを，機密性に基づいた一方向通信をもとに各権限に
応じて複数に分割することで，OS がプロセスの入出力を完全に制御できるようにするものである．
プロセスがどのような情報を扱い，またそれがどこに出力されるかについて，OS の制御が可能と
なるため，機密情報がネットワークなどの不当な出力先に出力されることを防ぐことができる．
また，Linux に対する本手法の実装を検討する．アクセス制御の設定については
SELinux の
TE（Type Enforcement）を用いる．SELinux のプロセス間通信には脆弱性があるため，そうし
た欠陥を改善する手法について示し，改良された SELinux によって，プロセスを複数に分割する
セキュリティモデルの実装手法を示した．
目次
第1章
1.1
1.2
1.3
第2章
2.1
2.2
2.3
2.4
第3章
3.1
3.2
3.3
第4章
4.1
4.2
4.3
はじめに
1
背景
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
2
2
関連手法
4
インフォメーションフロー制御手法
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . . . . . . . .
デジタル著作権管理 . . . . . . . .
SELinux . . . . . . . . . . . . . .
2.4.1 LSM . . . . . . . . . . . . .
2.4.2 セキュリティポリシー . . . .
2.4.3 セキュリティコンテキスト .
2.4.4 SELinux のアクセス制御 . .
2.4.5 一つのプロセスに権限を集約することの問題
アクセス制御
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
5
6
6
7
7
7
9
10
プロセス細分化によるセキュリティモデル
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
セキュリティ・レベル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
プロセス間通信の一方向性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
プロセスの制御
13
プロセス間通信の一方向性
SELinux のプロセス間通信時の脆弱性 . . . . .
4.1.1 非ブロック通信による漏洩 . . . . . . . .
4.1.2 System V IPC 資源の存在確認による漏洩
4.1.3 SELinux の対応状況 . . . . . . . . . . .
アタック・コードの例 . . . . . . . . . . . . . .
SELinux へのアクセス・ベクターの追加 . . . .
4.3.1 送信をブロック送信に限定 . . . . . . . .
4.3.2 IPC 資源の存在の検知を禁止 . . . . . . .
i
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13
13
14
14
15
16
16
17
第5章
5.1
5.2
第6章
6.1
6.2
SELinux を用いた SL の実現手法
19
. . . . . . . . . . . . .
SL に応じたアクセス制限 . . . . . . . . . . . .
5.2.1 SL が互いに等しいプロセス . . . . . . . .
5.2.2 高 SL プロセスと低 SL プロセス間の制限
ドメイン／タイプの定義
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
20
20
20
23
おわりに
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
今後の課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
まとめ
24
参考文献
ii
図目次
2.1
2.2
2.3
. . . . . . . . . . . . . . . . . . . . . . . . . . .
TE を記述したセキュリティポリシー例 . . . . . . . . . . . . . . . . . . . . . . .
ドメイン遷移を記述したセキュリティポリシー例 . . . . . . . . . . . . . . . . . .
3.1
3.2
複数の出力先が許可されたプロセスの概念図
4.1
4.2
アタック・コード（送信側）
5.1
5.2
5.3
5.4
5.5
同じ SL をもつ資源に対してアクセスを許可するポリシー記述例
セキュリティコンテキストの例
提案するプロセス細分化手法の概念図
アタック・コード（受信側）
7
8
8
. . . . . . . . . . . . . . . . . . . . 11
. . . . . . . . . . . . . . . . . . . . . . . . 11
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
.
低 SL から高 SL プロセスを起動可能にするポリシー記述例 . . .
高 SL から低 SL のファイルアクセスを制限するポリシー記述例 .
2 種類の通信用資源を用いる概念図 . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
新たに導入したアクセス・ベクターにより通信の一方向性を高めたポリシー記述例
iii
20
20
21
21
22
表目次
4.1
4.2
. . . . . . . . . . . . . . . . . . . 17
エラーコードを 1 つに限定するアクセス・ベクター . . . . . . . . . . . . . . . . 17
5.1
5.2
本章の記述例で用いるドメイン／タイプ .
非ブロック通信を禁止するアクセス・ベクター
デバイスの関連付け
. . . . . . . . . . . . . . . . . . . . . . 19
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
iv
第1章
1.1
はじめに
背景
情報機器の急速な発達とその低廉化に伴って，コンピュータシステムが扱う情報は多様化し続け
ており，ありとあらゆる情報がディジタルデータとして活用，保存されている．また，広帯域のイ
ンターネットが広く普及したため，ディジタルデータの送受信がより高速かつ容易になり，ソフト
ウェアや音楽，映像などのコンテンツがオンラインで提供されるようになってきている．しかし，
情報のディジタル化はこうした利便性を生む一方で，情報漏洩という大きな弊害を生じさせてい
る．ここでいうところの情報漏洩とは，情報の作成者・権利者の意図に反する形で情報が取り扱わ
れる事象を指す．
個人情報や企業の機密情報，商用マルチメディアコンテンツなどにおいては，それらの漏洩が社
会問題となっている．漏洩した情報はインターネットによって短期間に広く流通し，その回収は困
難であるため，情報漏洩の被害は甚大なものとなる．winny などの P2P ソフトウェアを経由した
著作権侵害に該当する情報漏洩は，何人もの逮捕者を出しつつも，収まる気配を見せない．
コンピュータシステムから情報が漏洩する原因は，ユーザの悪意や過失をはじめとして，スパイ
ウェアやトロイの木馬といったマルウェア，脆弱性を持ったプログラムに対する外部からの攻撃な
ど，多岐に渡る．
従来の情報漏洩対策では，個々の情報漏洩の原因に応じていくつかの手法が用いられている．主
な手法として，セキュア OS の MAC（強制アクセス制御）や，Java アプレット実行環境のサンド
ボックスモデルなどに見られる，アプリケーションの入出力を制限する手法，ならびに Windows
Media DRM のようなディジタル著作権管理システムが挙げられる．
アクセスを制御する方式では，あるアプリケーションに対し，情報の出力を単一の出力先に限定
する場合に限り，情報漏洩防止に有効である．しかし，複数の出力先が許可された場合については
問題が発生する．例えばインターネットに接続可能な音楽プレーヤは，OS によりネットワークへ
のアクセスとスピーカへの出力が許可されることになる．この場合，プレーヤが再生する保護され
た音楽コンテンツの情報がネットワークに出力されているかどうかについて，OS 側のみで検知・
制御をすることができない．サンドボックスモデルについても，厳しいアクセス制限を課してアプ
リケーションの挙動をごく一部に限定している状態ではセキュリティが保たれるが，アプリケー
ションの利便性を高めるために一定の権限を許可した場合については同様の問題が発生する．この
ため，これらはアプリケーションを信頼することを前提として成立しているセキュリティモデルで
あると言える．
ディジタル著作権管理システムでは，音楽データなどのコンテンツが暗号化された状態で配布さ
1
れ，Windows
Media Player のような専用プログラムがそれを復号化し，コンテンツを再生する．
一般にディジタル著作権管理システムでは，コンテンツを復号可能なプログラムを専用プログラム
に限定し，その専用プログラムの信頼性を高めることでコンテンツを保護している．しかし，復号
化処理をプログラム内部で行っているため，コンテンツ保護の強度はプログラムの耐タンパ性に依
存する．プログラムの耐タンパ性は暗号強度に比べ，その向上が困難であり，リバースエンジニア
リングなどの手段によってコンテンツが漏洩する恐れがある．また，コンテンツの再生が復号可能
なプログラムが専用プログラムに限定されることは，ユーザの利便性を損ねる．
このように，既存の情報漏洩対策技術は，プログラムにバグや欠陥がなく，外部からの攻撃に対
して完璧である，という前提においてうまくはたらく．しかし，ユーザ環境で利用されるプログラ
ムは多岐にわたっており，プログラム作成者がプログラムの信頼性を保証したり，ユーザがプログ
ラムの信頼性を判断することは，一般に極めて困難である．
1.2
目的
本研究は，実行されるアプリケーションプログラムの信頼性に依存することのないセキュリティ
機構を搭載した OS の実現を目的とする．
インフォメーションフロー追跡の困難性により，プロセスが現在扱っている情報が機密情報を含
むものであるのかそうでないのかということを判断することは不可能である．そのため，プロセス
が出力する情報すべてについて潜在的に情報漏洩の危険が存在することになる．情報漏洩防止のた
めにはプロセスが出力するあらゆる情報を制御しなければならない．
そこで，本研究ではプロセスの入出力に着目する．従来複数の権限が与えられていたプロセスを
細分化し，各々のプロセスに許可する出力先を限定することを考える．
保護されるべき機密情報にはそれぞれ，本来望ましい情報の出力先が存在する．それをセキュリ
ティ・レベルという指標を用いて一対一で対応付ける．また，同じ指標をプロセスについても関連
付ける．
あるセキュリティ・レベルをもつファイルは，同じセキュリティ・レベルをもつプロセスのみが
アクセス可能であるとする．そのプロセスは情報漏洩に該当する出力先にアクセスすることが禁じ
られているため，情報漏洩の防止が実現する．
1.3
構成
本論文では以下の構成を取る．
1 章では，情報漏洩防止技術が望まれる背景，および本論文の目的・構成について説明する．
2 章では，既存の情報漏洩防止を目的とした技術について述べる．また，本論文では SELinux
を用いた実装の検討をおこなうため，SELinux の機能について説明する．
3 章では，本論文で提案する，アプリケーションを信頼しないセキュリティモデルについて説明
し，セキュリティ・レベルという概念を導入する．
2
4 章では，SELinux が抱えるプロセス間通信時のセキュリティホールについて説明する．その脆
弱性に対応した新たなアクセス・ベクターを追加することで，プロセス間通信の一方向性を実現す
る提案をおこなう．
5 章では，4 章での改良をもとに，SELinux の TE を用いてセキュリティ・レベルを実装する手
法を提案する．
最後に 6 章で，本論文のまとめと，今後の課題について述べる．
3
第2章
関連手法
本章では既存の情報漏洩防止手法について説明する．
アプリケーションを信頼しない技術としてインフォメーションフローの制御を試みる手法も提
案されているが，その実現は困難である．アクセス制御方式やディジタル著作権管理手法について
は，アプリケーションの信頼性を前提として成立するため，情報漏洩の防止を OS 単体で保証する
ことはできない．
また，本論文では SELinux の機能を利用した実装についての提案をおこなうため，SELinux に
ついて細かく説明を加える．
2.1
インフォメーションフロー制御手法
情報の流れのことをインフォメーションフローと呼ぶ．インフォメーションフローを適切に制御
しようと試みることで，情報漏洩防止の実現を目指す手法がある．
栗田による動的なインフォメーションフロー制御による情報漏洩防止手法 [3] は，プロセッサが
実行する命令を観測することにより，機密情報のフローに携わったレジスタ／メモリに出力制限
ビットを付加し，そうしたレジスタ／メモリに保持された情報の出力可否をプラットフォーム側で
判断できるようにして，情報漏洩防止を実現しようとしたものである．
代入や演算などのデータフローに伴う明示的インフォメーションフローの動的追跡については，
該当するプロセッサの命令を単に追うことで可能となる．しかし，分岐命令やジャンプ命令など，
コントロールフローに伴う暗黙的インフォメーションフローは，完全な動的追跡は不可能であると
いう性質をもつ．それゆえ，インフォメーションフローの追跡および制御による情報漏洩防止手法
は，必ず何かしらの妥協をしなくてはならないという問題を抱えている．
2.2
アクセス制御
OS によるアクセス制御
UNIX 系 OS をはじめとする標準的な OS では，ファイルなど各種リソースへのアクセスに際し
て，任意アクセス制御（DAC: Discretionary Access Control）と呼ばれるアクセス制御を行って
いる．DAC はユーザ ID あるいはグループ ID に基づいてリソースの読み出し，書き込み，実行の
各権限を制御する方式であり，アクセス権限の設定はリソースの所有者が行う．
DAC には以下のような問題点がある．
4
• リソースの所有者がそれぞれ自由にアクセス権限を変更できるため，システム全体の設定を
一元的に管理することが困難である．
• スーパユーザと呼ばれる特別なユーザ（root）が存在し，root はすべての権限を許可され
る．そのため root 権限で動作するプログラムに乗っ取りが発生した場合，すべてのリソー
スが情報漏洩の危機に晒される．
これに対して，SELinux などのセキュア OS では，強制アクセス制御（MAC: Mandatory Access
Control）と呼ばれるアクセス制御を行う．MAC ではセキュリティポリシーによるアクセス制限
の一元管理や，特権ユーザである root の権限を大幅に縮小するなど，DAC のセキュリティホール
を改善し，外部アクセスによるプログラムの乗っ取りが発生した場合でも，被害が及ぶ領域が一部
に限定されるように設計されている．
アプリケーションに対し単一の権限のみを与えるようセキュリティポリシーを記述することで，
アプリケーションの挙動に依らず出力先は唯一に限定される．しかし，複数権限が与えられている
アプリケーションが，機密情報の出力を適切なデバイスのみに限定するかどうかについては，OS
が制御することができず，結局のところアプリケーションの信頼性に依存してしまうという問題が
ある．
サンドボックスモデル
アクセス制御技術と関連して，サンドボックスというセキュリティモデルがある．サンドボック
スモデルでは，外部と隔絶され保護された領域（サンドボックス）を作成し，その中でのみアプリ
ケーションを動作させることでセキュリティを実現する．アプリケーションはサンドボックス外に
対して全ての制限を負う．例として，Java アプレットはサンドボックス内で動作し，ローカル資
源へのアクセス禁止や，通信先サーバの限定などの制限を負う．
こうした制限はアプリケーションの利便性を大きく損ねる．java アプレットではセキュリティ
ポリシーによってアプリケーションを認証し，適切なアプリケーションに対しては制限を解除する
という手法を取り，利便性の向上をはかっている．
しかしこれは，先のアクセス制御と同様，認証されたアプリケーションの信頼性を前提としたセ
キュリティモデルとなる．認証されたアプリケーションに欠陥や攻撃があった場合，情報漏洩を防
ぐことはできない．
2.3
デジタル著作権管理
デジタル著作権管理（DRM:
Digital Rights Management）システムでは，デジタルコンテン
ツの著作権者がユーザに対して特定の使用規約を履行させるためのメカニズムを実現する． DRM
システムの例としては，Windows RM や，Apple による FairPlay，Adobe による AdobeDRM な
どが挙げられる．
デジタルコンテンツはユーザからの不当なアクセスを防止するための保護を行う必要がある．そ
5
のため DRM システムでは，作成されたデジタルコンテンツを DES や AES，あるいはシステム独
自のアルゴリズムによって暗号化する．ユーザがデジタルコンテンツを利用する際には，ライセン
スを取得し，認証された専用のアプリケーションを用いてコンテンツへとアクセスする．認証され
たアプリケーションがライセンスに基づいた制御を行うため，ライセンスに違反したコンテンツの
利用は防止される．
このような DRM システムは，前述の通り専用のアプリケーションを用いてコンテンツへアクセ
スすることを要求する．既存の DRM システムにおいては，専用のアプリケーションの仕様が公開
されていない場合が多い．これはアルゴリズム秘匿などの点で保護方式の安全性を高めるためであ
るが，一方で DRM システムの提供者以外が DRM システムによって認証されるアプリケーショ
ンを作成することを不可能にしている．このためユーザは，DRM システム提供者が配布している
アプリケーションを使わざるを得ない．
たとえば，動画再生アプリケーションは多数存在するが，Windows
る動画ファイルは Windows
Media DRM を使用してい
Media Player でのみ再生が可能となる．このようにコンテンツ再生
アプリケーションが限定されてしまうため，ユーザの利便性を損なう問題がある．
また，DRM システムにおいては，暗号化され保護されたコンテンツのセキュリティが守られる
かどうかは，ひとえに専用アプリケーションの耐タンパ性に依存する．悪意あるユーザが専用アプ
リケーション対し攻撃をおこなうことで，コンテンツの保護が破られてしまう危険性を常に孕んで
いる．
前節のアクセス制御方式同様，DRM システムについても，アプリケーションへの信頼を前提に
成立するセキュリティ方式であると考えられる．
2.4
SELinux
Security-Enhanced Linux（以下 SELinux）とは，米国家安全保障局（NSA）が中心となって開
発した，Linux にセキュア OS の機能を持たせるセキュリティ強化モジュールである [5, 6]．Linux
カーネルに組み込まれている LSM（Linux Security Modules）を用いて，Linux に強制アクセス
制御機能を付加し，セキュリティ管理者が定めたセキュリティポリシーに基づいて，一元的にファ
イルやデバイスの入出力を制御する．
本論文では，SELinux を応用した実装の提案をおこなう．それゆえ，関連する機能について本節
で説明を加えるものである．
2.4.1
LSM
LSM（Linux Security Modules）とは，各システムコールにおいてアクセス権チェックの必要
な場所に配置されたフック関数の集合である．Linux にセキュリティ機能を付加するモジュールは
SELinux 以外にも多数あるが，どのアクセス制御手法を用いるにしても，アクセスの正当性を判断
すべき場所というのは一律であるとして採用された．現在 187 種類のフック関数が定義されてお
6
り，Linux カーネル v2.6 系列の標準機能となっている．
LSM 関数は各システムコールに埋め込まれ，システムコールが呼び出される毎に実行の正当性
を判定できるようになっている．この LSM 関数群に任意の関数をフックすることで，独自のアク
セス権判定機構をシステムコールに実装することができる．SELinux をはじめとして，他の Linux
用セキュリティ強化モジュールである TOMOYO Linux，AppArmor，Smack などもこの LSM
を利用してセキュリティ機能を実装している．
2.4.2
セキュリティポリシー
SELinux が用いるセキュリティポリシーは，「誰が・何に・何が可能か」というルールの集まり
である．ホワイトリスト方式が採用されており，明示的に記述されていない操作は全て禁止され
る．ポリシー上の「誰が」および「何に」を識別するための識別子は，次のセキュリティコンテキ
ストで与えられる．
2.4.3
セキュリティコンテキスト
SELinux はプロセスやファイル，ソケット，共有メモリなどにセキュリティコンテキストと呼ば
れる新たな属性を付与し，これを識別子としてアクセス制御を実行する．
dbadm_u
: system_r : httpd_t : s0 図 2.1 セキュリティコンテキストの例
2.1 にみられるように，コロンで区切られた 4 つのフィールド
から成る．それぞれ SELinux のアクセス制御機構で用いられるが，本提案では左から 3 番目の
フィールド（図 2.1 における httpd_t）である，ドメイン／タイプのみを用いる．
セキュリティコンテキストは図
2.4.4
SELinux
のアクセス制御
TE
TE（Type Enforcement）は SELinux における中核的なアクセス制御方式であり，セキュリ
ティポリシーの大半は TE を表現するルールである．「誰が・何に・何が可能か」という対応関係
をホワイトリスト方式で逐一記述して，プロセスが実行可能な操作を限定する．
操作の主体となるプロセス及び対象となるオブジェクトの識別子は，前節で見た"ドメイン／タ
イプ"フィールドに与えられる．ドメインとタイプの違いは，プロセスに付与される識別子はドメ
インと呼ばれ，プロセス以外のオブジェクトの場合はタイプと呼ばれるのみであり，呼び方が異な
るのみで実質は特に区別のないものである．
TE の 例 を 図 2.2 に 示 す ．こ の 例 の 1 行 目 で は ，http_d ド メ イ ン を も つ プ ロ セ ス が ，
httpd_sys_content_t タイプをもつファイルに対して read 操作を行うことを許可する．2 行目
7
では，webadm_t ドメインをもつプロセスが，httpd_sys_content_t タイプをもつソケットに対
して read 及び write 操作を行うことを許可する．ホワイトリスト方式であるため，明示的に記述
された上記操作以外は全て禁止される．
図 2.2 に見られるようなポリシーの記述において，le や socket などオブジェクトの種類を表す
識別子をオブジェクト・クラス，read や write や open などオブジェクトごとに許可する操作を表
す識別子をアクセス・ベクターと呼ぶ．4 章にて，新たにアクセス・ベクターを追加することによ
る SELinux の改良手法を提案する．
allow httpd_t httpd_sys_content_t : le { read };
allow webadm_t httpd_sys_content_t : socket { read write };
図 2.2
TE
を記述したセキュリティポリシー例
ドメイン遷移
あるプロセスが子プロセスを生成して別のプログラムを実行するとき，基本的には親プロセスの
セキュリティコンテキストを受け継ぐ．そのため，たとえばログイン時に sta_t というドメイン
が割り当てられたログインシェルが，子プロセスとして更に vi や less などを起動した際には，そ
れらのプロセスも sta_t ドメインとなり，ログインシェル同様のアクセス制限が課される．
しかし，新たに生成した子プロセスに親プロセスとは別のドメインを付与したい場合もある．そ
うした要求のため，TE にはドメイン遷移という機能が用意されている．ドメイン遷移を用いると，
execve システムコールの実行時に，プロセスのドメインを所望のものに切り替えることができる．
allow initrc_t httpd_exec_t : le { getattr open read execute };
allow initrc_t httpd_t : process { transition };
type_transition initrc_t httpd_exec_t : process http_t;
図 2.3
ドメイン遷移を記述したセキュリティポリシー例
ドメイン遷移を記述するルールの例を図
2.3
に示す．initrc_t ドメインをもつプロセスが，
http_exec_t タイプをもつファイルを実行した際に，プロセスが httpd_t ドメインに遷移するよ
うに設定されている．
この例では，1 行目で，initrc_t ドメインのプロセスが httpd_exec_t タイプのファイルの実行
を許可している．2 行目で，initrc_t ドメインのプロセスが
httpd_t ドメインのプロセスへと遷
移することを許可し，3 行目で，initrc_t ドメインをもつプロセスが httpd_exec_t タイプをもつ
ファイルを実行した際に，プロセスのドメインが httpd_t に遷移するというイベントが発生する
ように指示している．
また，1 行でドメイン遷移を記述する，domain_trans というマクロも利用可能である．
8
RBAC・MLS
TE 以外にも，SELinux に実装されているアクセス制御方式には，プロセスに付与されたロール
に応じて，遷移可能なドメインを制御する RBAC（Role Based Access Control）や，機密レベル・
機密カテゴリの値に応じて read 系操作と write 系操作を制御する MLS（Multi Level Security）
があるが，本論文ではこれらの機能を利用しないため，ここでの説明は割愛する．
2.4.5
一つのプロセスに権限を集約することの問題
SELinux のアクセス制御を用いることで，プロセスやファイルに応じて厳密なアクセス制限を
課すことができる．しかしながら，同一のプロセスにネットワークへの出力許可，および機密情報
へのアクセス許可の両方を与えた場合には，機密情報に由来する情報がネットワークに出力される
かどうかについて，ただアプリケーションの信頼性のみに依存することになる．アプリケーション
作成者が悪意をもっていた場合や，外部からの攻撃によりアプリケーションの欠陥を突かれた場合
に，情報の漏洩を防ぐ手立てはない．
そこで本提案では，1 つのアプリケーションを複数プロセスに分け，片一方にはネットワークの
出力許可を与え，もう片方には機密情報へのアクセス許可を与える，というアプローチを採る．こ
れにより 1 つのプロセスに権限が集約することが避けられ，OS が単独で情報の流れをコントロー
ルすることが可能となる．
次章では，本提案の核となる情報漏洩を防止する
する．
9
OS の実現へ向けたアプローチについて説明
第3章
プロセス細分化によるセキュリ
ティモデル
アプリケーションの信頼性に依存せず，OS のみで情報漏洩防止を実現するためのアプローチと
して，プロセスを細分化することにより出力先を限定する手法を提案する．
また，セキュリティ・レベルという指標を導入し，それをファイルやプロセス等と関連付けるこ
とによって，扱われる情報と望ましい出力先の対応付けを，OS が管理・制御できるようにする．
3.1
プロセスの制御
一般に，コンピュータが情報を取り扱う際に，その主体となるのはプロセスである．情報のフ
ローは必ずプロセスを介して発生する．したがって，OS 側でプロセスが読み込み可能な情報及び
出力可能なデバイスを制御することができれば，アプリケーションの信頼性に依存しない情報漏洩
防止 OS が実現する．
これまで見てきたように，既存手法の問題点は，ひとつのプロセスに複数の権限が許可されるこ
とにあった．ネットワークに出力されることが望まれていない音楽ファイルを，ネットワークデバ
イスへの出力許可が与えられているプレーヤで再生するとき，その音楽ファイルがネット上に流
出するかどうかは，OS の制御を離れ，ひとえにアプリケーションの信頼性にのみ依存することに
なる．
機密情報には，それぞれ情報の権利者にとって本来望ましい情報の出力先が存在する．保護され
た音楽ファイルであれば，スピーカへの出力のみが許可され，ネットワークへの出力は禁止される
べきである．社内機密文書であれば，特定ドメインのネットワーク出力は許可されるべきである．
機密情報に応じ，出力可能デバイスがそれぞれ関連付けられ，それを取り扱うプロセスは該当する
デバイスのみに対して出力が許されなければならない．
本論文では，異なる出力先に応じてプロセスを個別に生成するというアプローチを採る．生成さ
れたプロセスは，OS により必要最低限のアクセス許可のみが与えられる．また，それぞれのプロ
セスに対して，アクセス可能なファイルを関連付ける．
先のネットワークにアクセス可能な音楽プレーヤを例にとり説明する（図 3.1，3.2）．もともと
1 つであったプロセスをまず 2 つに分割する（プロセス A ／ B とする）．プロセス A にはネット
ワークのアクセス許可を与える．プロセス B にはスピーカへの出力許可を与え，ネットワークへ
のアクセスは禁止する．また，保護された音楽ファイルは，プロセス B のみが読み出せるように
関連付ける．これによりプロセス A は保護された情報を扱うことができず，プロセス A がネット
10
ワークに出力する情報には保護された情報が含まれていないことが OS により保証される．
ࢼஹƷȗȭǻǹ
ȍȃȈȯȸǯ
ǵǦȳȉȇȐǤǹ
図 3.1 複数の出力先が許可されたプロセスの概念図
ȗȭǻǹ #
ȗȭǻǹ $
˯ 5.
᭗ 5.
ɟ૾Ӽᡫ̮
ȍȃȈȯȸǯ
図 3.2
ǵǦȳȉȇȐǤǹ
提案するプロセス細分化手法の概念図
11
セキュリティ・レベル
3.2
図 3.2 の例では，プロセス B はプロセス A よりも機密度が高い情報を扱うことができ，相対的
に機密度がより高いプロセスであるということが言える．このように，プロセスが出力可能なデバ
イスに応じて，プロセス間で機密度の上下関係が発生する．プロセス毎に関連付けられた機密性の
ことを，セキュリティ・レベル（以下 SL）と定義する．
また，プロセス 2 者間の SL を比較した際に，考えられる関係として，
• SL に上下関係がある
• SL が互いに等しい
• 互いの SL について関係性が不明瞭・無関係
の 3 点が挙げられる．
以降では，互いに SL の上下関係が認められるとき，相対的に機密度が高いプロセスを高 SL プ
ロセス，機密度が低いプロセスを低 SL プロセスと呼ぶものとする．
プロセス間通信の一方向性
3.3
高 SL プロセスから低 SL プロセスへ情報が流れると情報漏洩の危険を含むため，これは OS が
禁止する．関係性が互いに不明瞭なプロセス同士に関しても，情報がどのように扱われるか不明な
ため，通信を禁止する．
一方，本来ひとつだったプロセスをいくつかに細分化するため，細分化する前と同等の仕様が達
成できるように，全体でひとつのアプリケーションとして各プロセスが協調して動作しなくてはな
らない．協調動作のためには，低 SL プロセスから高 SL プロセスへは情報を伝達できる機能が必
要である．
以上より，
• 高 SL から低 SL へは情報の伝達を禁止する
• 低 SL から高 SL へは情報の伝達を許可する
という，プロセス間通信の一方向性もまた満たすべき要件となる．
Linux を例にとると，各プロセスは，ファイルやソケットなど OS が用意した各種資源を利用し
てプロセス間通信をおこなう．この資源に対して，低 SL プロセスが書き込み専用，高 SL プロセ
スが読み込み専用と定めることで，プロセス間通信の通常用途においては通信の一方向性が確保さ
れる．
しかしながら，プロセス間通信に用いるバッファの状態を，エラーの有無を利用して送信側が観
測できてしまう問題がある．次章ではその問題について説明を加える．
12
第4章
プロセス間通信の一方向性
3 章で述べた，プロセスを SL 毎に分割するセキュリティモデルについて，本章と次章では
SELinux を用いた実装について検討する．
プロセスがアクセス可能なファイル・ディレクトリの対応付けや，出力可能なデバイスの制限，
プロセス間通信資源への入出力制限等は SELinux の TE を利用することで実装可能である．
しかし一方で，現行 SELinux においては，プロセス間通信の完全な一方向性を実現することが
できない．低 SL プロセスを送信専用に限定したとしても，送信時のエラーコードを介して，十分
な転送速度での情報漏洩を引き起こすことが可能となる．
本章では，SELinux が抱えるプロセス間通信時の脆弱性について説明し，その脆弱性を突くア
タック・コードの例を示す．その上でそうした漏洩手法に対応した
SELinux の改良手法を提案
する．
4.1
SELinux
のプロセス間通信時の脆弱性
SL・低 SL 間でのプロセス間通信の一方向性を実現するために，SELinux の TE を用いて，
低 SL プロセスには送信許可のみを，高 SL プロセスには受信許可のみを与える．しかし，現行
SELinux にはプロセス間通信時に脆弱性が存在するため，それだけでは不十分である．
高
4.1.1
非ブロック通信による漏洩
パイプやソケットなどの通信では，受信側が読み込み操作をおこなうことでバッファやキューか
らデータが取り除かれる．ゆえに，高 SL プロセスはバッファに対し「空き容量がある」
「空き容量
がない」という 2 状態を操作することが可能となる．2 状態を操作することで 1 ビットの表現に相
当するため，この情報を低 SL プロセス側で観測することができれば情報漏洩につながってしまう．
低 SL プロセスがバッファの状態を観測するには，送信が成功したか失敗したかを確認するだけ
で良い．送信システムコールが成功すれば「空き容量がある」，失敗すれば「空き容量がない」と
いうことがわかる．
送信システムコールにはブロック送信モードと非ブロック送信モードを指定することができる．
ブロック送信モードの場合は，送信が失敗した際にバッファに空きができるまでプロセスはブロッ
クされる．ゆえに，システムコールの失敗が検知できたとしても，プロセスの応答性が下がるた
め，時間当たり漏洩する情報量としては安全であると考えられる．
一方，非ブロック送信ではシステムコールが失敗した場合に即座にプロセスに制御を戻してしま
13
う．これによりバッファの状態を即座に判断することが可能である．このことを用いると，高 SL
プロセスから低 SL プロセスへ高速な情報漏洩を引き起こせる．
また，パイプに対する非ブロック通信では，より高速な情報の漏洩が可能である．バッファに十
分な空き容量がないときに，パイプに対して write システムコールを非ブロックモードで実行す
ると，書き込み可能なバイト数のみを書き込み，実際に書き込んだバイト数が返り値として返され
る．このことを利用して，受信側でバッファの空き容量を適切に操作することにより，一度に複数
ビットの漏洩を発生させることが可能となる [2]．
4.1.2
System V IPC
資源の存在確認による漏洩
System V IPC 資源にはセマフォ，メッセージキュー，共有メモリがある．これらを利用するに
は，送受信に加えて，取得操作（associate）の許可が必要である．そのため，SELinux は，低 SL
プロセスに対して送信専用のセキュリティポリシーとして write ならびに associate を許可する．
このとき，高 SL プロセスが作成した IPC 資源の存在を問い合わせることによる情報漏洩が考え
られる．
プロセスが IPC 資源の取得を試みたとき，指定したキーに該当する IPC 資源が存在していない
ならば，エラー ENOENT でシステムコールは失敗する．一方，既に該当する IPC 資源が存在して
いる場合，SELinux のセキュリティポリシーに反する取得操作に対してはエラー EACCES でシス
テムコールは失敗する．
つまり，SELinux によるアクセス制限が有効になっていた場合でも，２種類のエラーコードを比
較することにより，低 SL プロセスが１ビットの情報を得ることが可能となる．
4.1.3
SELinux
の対応状況
現行の SELinux はこうした問題に対応できていない．以下に概略を示す．
送信時のフラグを検出しない問題
send システムコールを例にとって説明する．send システムコールは，
sys_send() → sys_sendto() → sock_sendmsg() → __sock_sendmsg()
の順で関数を経由して処理が実行される．このとき，関数__sock_sendmsg 内で，LSM 関数であ
る security_socket_sendmsg 関数が呼び出される．この LSM 関数から SELinux のフック関数
が呼ばれ，SELinux のアクセス制御処理が実行される．アクセス制御をおこなう関数を更に追跡
すると，
security_socket_sendmsg() → selinux_socket_sendmsg() → sock_has_perm()
の順で処理が実行される．
14
SELinux
に お い て ，ソ ケ ッ ト 関 連 の ア ク セ ス 制 御 処 理 を 実 際 に お こ な っ て い る の は
sock_has_perm 関数であるが，この関数には送信時のフラグを格納した変数が渡されておらず，
フラグの正当性は一切評価されていない．SELinux では，送信操作の禁止／許可を設定すること
はできるものの，送信許可を与えられたプロセスが送信時にどのようなオプションを設定するか，
というところまでは制御が及んでいないのが実情である．
複数のエラーコードが発生する問題
SELinux のアクセス制御に違反した場合，エラーコードは一律 EACCES となる．このため，
SELinux のアクセス制御処理に制御が移る前に，EACCES 以外の何らかのエラーが発生しうる場
合，2 種類以上のエラーコードが送信プロセスに渡される可能性があることになる．
4.2
アタック・コードの例
4.1.1 節で見たように，送信側プロセスは非ブロック通信を用いることで，バッファに空きがあ
るかどうかについての情報を即座に得ることができる．このことを利用したアタック・コードの例
を図 4.1 と図 4.2 に示す．
これらは受信専用プロセスから送信専用プロセスへ 1 バイトの漏洩を発生させるコードの主要部
分である．送信専用のプロセスにもかかわらず，エラーの発生を問い合わせることで，受信プロセ
スから情報を受け取ることが可能となる．
この例では，3 つの UNIX ドメインソケット（s1，s2，s3）を用い，プロセス間で同期を取りな
がら受信側から送信側へと情報を漏洩している．すなわち，
1. s1 と s2 のバッファを事前に満たしておく．s3 は空にしておく．
2. 送信側は s2 が空くまで送信を試み続ける．受信側が漏洩データをセットするまで待つ．
3. 漏洩させたいビットが 1 ならば受信側が s1 から読み込む．0 ならばなにもしない．
4. 受信側は s2 から受信し，送信側にデータセットの完了を伝える．
5. 受信側は s3 に何か書き込まれるまで受信を試みる．送信側が情報を取得するまで待つ．
6. 送信側は s1 に書き込みを試みる．成立すれば 1，エラーが発生すれば 0 であることがわ
かる．
7.
送信側は s3 に書き込み，情報を取得したことを受信側に伝える．
ということを繰り返しおこなっている．このような単純なコードでも，数 10kb/s 以上の速度で情
報を伝達することが可能であることを当研究室で確認している．
15
for (i = 0; i < 8; i++) {
while (send(s2, buf, BUFSZ, MSG_DONTWAIT) < 0)
;
if (send(s1, buf, BUFSZ, MSG_DONTWAIT) >= 0)
data |= mask;
mask <<= 1;
send(s3, buf, BUFSZ, 0);
}
図 4.1 アタック・コード（送信側）
for (i = 0; i < 8; i++) {
if (mask & data)
recv(s1, buf, BUFSZ, 0);
mask <<= 1;
recv(s2, buf, BUFSZ, 0);
while (recv(s3, buf, BUFSZ, MSG_DONTWAIT) < 0)
;
}
図 4.2 アタック・コード（受信側）
4.3
4.3.1
SELinux
へのアクセス・ベクターの追加
送信をブロック送信に限定
これまで見てきたように，SELinux の LSM モジュール関数は，送信のシステムコールに付随す
るフラグについてのチェックをおこなわず，ひとたび送信の許可を与えたならば，ブロック通信と
非ブロック通信を区別しない．このため，十分な空き容量が無いバッファに非ブロック送信をおこ
なうと，エラー EAGAIN の発生により即時に 1 ビットの漏洩が発生する．
このセキュリティホールに対応するため，既存のアクセス・ベクター
write_block を追加する（表 4.1）．
16
write に対し，新たに
write
write_block
ブロック／非ブロック問わず書き込み操作を許可する
ブロック書き込みのみを許可する
表 4.1 非ブロック通信を禁止するアクセス・ベクター
非ブロック通信を指定するフラグは，ソケット通信における MSG_DONTWAIT，System
V IPC 関
連では IPC_NOWAIT であり，これらのフラグをチェックするコードを SELinux のフック関数に追
加する．また，ファイルオープン時，ないし fcntl システムコールを実行した際に，ファイル状
態フラグとして非ブロックモードを指定する O_NONBLOCK がある．このアクセス・ベクターが指定
されているプロセスにおいては，ファイル状態フラグを O_NONBLOCK とすることは禁止される．
4.3.2
IPC
資源の存在の検知を禁止
System V IPC 資源の存在確認により情報が漏洩する問題に対処する．shmget() 等の IPC 資源
を取得するシステムコールを IPC_CREAT フラグを立てずに実行すると，指定したキーに該当する
IPC 資源が存在しない場合にはエラー ENOENT が返る．一方，SELinux のセキュリティポリシー
に違反した場合は，かならずエラー EACCES が返る．このため，EACCES の場合は該当する IPC 資
源が存在し，ENOENT の場合は存在しない，という情報を低 SL プロセス側が観測できてしまう．
高 SL プロセスが，漏洩させたいビット列に合わせて IPC 資源の作成と削除を繰り返し，その都
度低 SL プロセスが存在確認をおこなうことで，1 ビットずつの情報漏洩が可能となる．
これに伴って，既存のアクセス・ベクター associate に加えて，secure_associate を追加する（表
4.2）．
associate
secure_associate
IPC 資源の ID の取得を許可する
IPC 資源の ID の取得を許可するが，発生するエラーは全て ENOENT
に限定する
表 4.2 エラーコードを 1 つに限定するアクセス・ベクター
低 SL プロセスが高 SL プロセスの資源を利用することは禁止するため，IPC 資源を取得するシ
ステムコールは必ず失敗することになるが，エラーが 2 種類以上存在することにより任意の 1 ビッ
トの漏洩につながってしまう．この種の情報漏洩を防ぐには，システムコールが設定するエラー値
を 1 種類に限定する必要がある．
IPC 資源がまだ存在していない状態では，低 SL プロセスがアクセスを試みた IPC 資源の SL
が確定していないため，そのアクセスが不当かどうかを判断することはできない．したがって，エ
ラー ENOENT が発生する状況はかならず存在することになる．それゆえ，secure_associate を指定
したプロセスに対しては，セキュリティポリシー違反によるエラー EACCES や，既に該当する資源
が存在するエラー EEXIST をすべてエラー ENOENT に置き換えることで対応する．
17
このアクセス・ベクターが指定してあるプロセスにおいては，IPC 資源を取得する際に発生した
エラーは ENOENT のみとなる．
18
第5章
SELinux を用いた SL の実現手法
前章では，プロセス間通信において，エラーコード検知により通信の一方向性が破れる問題につ
いて説明し，そうした問題に対応できる新たな SELinux のアクセス・ベクターを提案した．
本章では，改良した SELinux を用い，3 章で提案したセキュリティ・レベルを実現する方法を
提案する．
5.1
ドメイン／タイプの定義
SELinux の TE を用いてアクセス制限をおこなう．SL の付与はプロセスに与えるドメイン，お
よびファイル等に与えるタイプを用いる．
本章でのポリシーの記述例においては，ドメイン／タイプとして，表 5.1 に示したものを用いる．
SL_X_t
SL_H_t
SL_L_t
SL_X_exec_t
SL_L_ipc_t
任意の SL のプロセスを表す際に用いる
高 SL プロセス・高 SL に関連付けられたファイル
低 SL プロセス・低 SL に関連付けられたファイル
任意の SL に対応した実行ファイルに付与
低 SL から高 SL への通信に用いるプロセス間通信用資源に付与
表 5.1 本章の記述例で用いるドメイン／タイプ
以下の節で高 SL プロセス・低 SL プロセス間でどのようにアクセス制限を定めるべきか示して
いく．セキュリティ・レベルは任意のプロセス 2 者間の関係性を表すため，任意の SL において課
された制限は，その SL より下位の全ての SL について成立する．
たとえば，SL1，SL2，SL3 の 3 つの SL を定義し，このうち SL3 が最高位の SL であるとする
と，SL3 が SL2 に対し負う制限は，SL1 に対しても全て当てはまる．
したがって，SL が多段の階層を成している場合，記述すべきポリシーは定義された SL の数だ
け増加する．記述例が煩雑になるため，ここでは上下関係をもつ任意の 2 者間のプロセスについて
の一般的な記述にとどめる．
19
5.2
5.2.1
SL
SL
に応じたアクセス制限
が互いに等しいプロセス
同じ SL をもつ別プロセス同士，ならびに自分自身に関連付けられたファイル／資源について，
必要とされるものには任意のアクセスを許可する．図 5.1 の記述例では，SL_X_t のプロセスに
対し，ファイル，ディレクトリ，ソケットに対して任意のアクセスを許可し，自分自身と同 SL の
プロセスを起動する権利を与える．
#同 SL のプロセス起動，ファイル／ディレクトリ／ソケットのアクセス許可
domain_trans( SL_X_t, SL_X_exec_t, SL_X_t )
allow SL_X_t self : le manage_le_perms;
allow SL_X_t self : dir manage_dir_perms;
allow SL_X_t self : sock_le manage_sock_le_perms;
図 5.1 同じ SL をもつ資源に対してアクセスを許可するポリシー記述例
また，別途プロセス間通信資源に対するアクセスも必要に応じて許可する．同じ SL であるため，
いかなる通信に関しても情報漏洩の危険はない．したがって，使用を許された資源に対しては，読
み書きや作成など，あらゆる操作が認められる．
5.2.2
高 SL プロセスと低 SL プロセス間の制限
高 SL に関連付けられたファイルは高 SL プロセスのみが扱えるようにする．また低 SL プロセ
スから高 SL プロセスへと切り替えることができるようにし，その逆は認めない．低 SL プロセス
から高 SL プロセスへ一方向的に情報が伝達できるようにする．
SL の切り替え
低 SL から高 SL のプロセスを起動できるようにする（図 5.2）．
#低 SL プロセスから高 SL プロセスの実行ファイルを起動し，SL を切り替える
domain_trans( SL_L_t, SL_H_exec_t, SL_L_t )
図 5.2 低 SL から高 SL プロセスを起動可能にするポリシー記述例
高 SL から低 SL のプロセスは起動できない．自身の SL より低位の SL に遷移することは許さ
れていない．
20
ファイル／ディレクトリの対応付け
ファイル／ディレクトリとプロセスの対応付けをおこなう（図 5.3）．
#高 SL プロセスから低 SL ファイルは読み込み専用とする
allow SL_H_t SL_L_t : le { getattr open read };
allow SL_H_t SL_L_t : dir { getattr search open };
図 5.3 高 SL から低 SL のファイルアクセスを制限するポリシー記述例
SL プロセスは低 SL のファイル／ディレクトリを読み込むことのみを許可する．SL ごとに
作成できるファイルは該当 SL のディレクトリに限定されるため，低 SL プロセスは高 SL プロセ
高
スのディレクトリを検索することができない．ファイル名やファイルサイズを観測することによる
情報の漏洩や，ファイルの存在の有無を確認することによる情報の漏洩は防止される．
プロセス間通信の制限
低 SL プロセスから高 SL プロセスへ一方向の通信がおこなえるよう，通信手段を確保する．前
章で提案したアクセス・ベクターを用い，低
SL プロセスからは非ブロック通信を禁止し，また
System V IPC 資源の存在を観測することも禁止する．
このとき，自プロセスが作成した資源を用いた通信については，5.2.1 節にて全てのアクセス許
可を既に与えてある．ゆえに，「同 SL 同士で通信するための資源」「低 SL から高 SL へ送信する
ための資源」をそれぞれ別途用意する必要がある．
SELinux の TE には，ディレクトリに応じて新規作成されるファイルのタイプを切り替えるタ
イプ遷移という仕組みがある．ソケットファイルはこれを用いて，高 SL へと通信する専用のタイ
プに切り替えるものとする．一方，System V IPC 資源に関しては，ファイルシステム上の資源で
はないため，SL 間通信専用の資源を作成するプロセスを新たに立ち上げ，そのプロセスが資源を
確保することでタイプを切り替えるものとする（図 5.4）．
SL_H_t
SL_L_t
ソケット
SL_L_t
図 5.4
2
SL_L_ipc_t
ソケット
SL_L_t
種類の通信用資源を用いる概念図
21
これらの操作は一般に煩雑でプログラマビリティを損なうため，タイプの異なる資源を作成でき
るシステムコールを追加する実装も考えられる．
異なる SL 間で通信する専用の資源（SL_L_ipc_t）を用意して，4.3 節で提案したアクセス・
ベクターを用いることにより，UNIX ドメインソケットのストリーム通信，および共有メモリの利
用を許可する記述例を図 5.5 に示す．
allow SL_L_t SL_L_ipc_t : sock_le { write_block };
allow SL_L_t SL_L_ipc_t : unix_stream_socket { write_block bind listen accept };
allow SL_L_t SL_L_ipc_t : shm { secure_associate read write unix_read unix_write };
allow SL_H_t SL_L_ipc_t : sock_le { read };
allow SL_H_t SL_L_ipc_t : unix_stream_socket { read connect };
allow SL_H_t SL_L_ipc_t : shm { associate read unix_read };
図 5.5 新たに導入したアクセス・ベクターにより通信の一方向性を高めたポリシー記述例
出力先デバイスの関連付け
SL ごとに入出力可能なデバイスを関連付ける．デバイスごとにタイプを設定し，allow 文や各
種マクロを用いてアクセスを許可する．たとえば dev_write_sound マクロはサウンドデバイスへ
の出力を許可するものである．任意の数の SL に任意のデバイスの入出力許可を設定可能であり，
柔軟なセキュリティモデルの実現が可能と考えられる．
表 5.2 に簡易な例を示す．SL1，SL2，SL3 の三種類の SL を用意し，
SL3
SL2
SL1
サウンド出力のみ
サウンド出力とビデオカード出力
サウンド出力，ビデオカード出力，ネットワーク出力
表 5.2 デバイスの関連付け
とすると，OS による保護機構がはたらいている以上，SL3 のファイルは SL3 プロセスしか扱う
ことができず，SL3 プロセスの出力先はサウンドデバイスに限定される．これにより，保護される
べき音楽ファイルのネットワーク上への漏洩を防止することができる．
22
第6章
6.1
おわりに
まとめ
本論文では，アプリケーションの信頼性に依存しない情報漏洩防止の重要性について述べ，また
プロセスが出力する情報すべてについて情報漏洩の疑いがあるとして，プロセスをセキュリティ・
レベルに応じて細分化することにより，OS がプロセスの出力先を一意に制御可能になるセキュリ
ティモデルを提案した．
この提案は，従来ひとつのプロセスに集中していた権限を，セキュリティ・レベルに応じて複数
プロセスに分散させ，それぞれのプロセスがアクセス可能なファイルを限定することにより成り立
つ．また，分散したプロセス同士が全体で一つのアプリケーションとして協調して動作できるよう
に，セキュリティ・レベルが低いプロセスからセキュリティ・レベルが高いプロセスへと一方向通
信ができなければならない．
非ブロック通信の検知および
IPC
資源取得時のエラーコードを限定化する改良を加えた
SELinux を用いて，本提案を実装する手法について示した．
6.2
今後の課題
SELinux のポリシーはホワイトリストで記述するため，実際に提案手法を実装するには，5 章で
示した記述例のみでは不完全である．セキュリティ・レベルごとに必要最低限のポリシー記述をど
のようにすべきかということについて実装上の検討課題である．
また，従来はひとつのプロセスで動いていたアプリケーションを，別途プロセスを細分化するこ
とで書き直さなければならない．このことについてプログラマビリティの低下や，動作上のオーバ
ヘッドについて懸念される．現在は簡易な音楽プレーヤを作成することにより，それらについての
評価を試みている．
23
参考文献
[1] DANIEL P. BOVET and MARCO CESATI. 詳解 LINUX カーネル 第 3 版. オライリー・
ジャパン, 2007. 高橋浩和 監訳, 杉田由美子, 清水正明, 高杉昌督, 平松勝巳, 安井隆宏 訳.
[2] Tresys Technology.
Securing inter-process communications in selinux.
www.tresys.com/pdf/Securing-IPC-in-SELinux.pdf, 2007.
[3] 栗田弘之. 動的なインフォメーションフロー制御による情報漏洩防止手法. Master's thesis, 東
京大学大学院情報理工学系研究科, 2007.
[4] 高橋浩和, 小田逸郎, 山幡為佐久. Linux カーネル 2.6 解読室. ソフトバンク クリエイティブ,
2006.
[5] 杉田由美子, 須崎有康（編）. 情報処理, 第 51 巻, Linux のセキュリティ機能. 情報処理学会,
2010.
[6] 中村雄一, 上野修一, 水上友宏. SELinux 徹底ガイド. 日経 BP 社, 2004.
[7] 横田侑樹. 情報漏洩防止プラットフォーム. Master's thesis, 東京大学大学院情報理工学系研究
科, 2010.
24
謝辞
本論文を完成させるにあたりまして，多くの方々のお世話にあずかりました．
坂井修一教授には，相談会等を通じ，様々なご指導をいただきました．また，五島正裕准教授に
は，学術的な指導や研究に対する心構えの教示に加え，様々な状況下で性根を叩き直してください
ました．深く感謝いたしております．
塩谷亮太氏をはじめとした先輩方からは，常に的確なご助言をいただき，また優秀な先輩方の後
ろ姿は，勉強を進めていく上で，大きな刺激となりました．
同期の皆のおかげで，研究室内では楽しく過ごせ，またしばしば様々な相談に乗っていただきま
した．
関わっていただいた方々すべてに，あらためて心より感謝申し上げます．
どうもありがとうございました．
25