LSM
のオーバーヘッド測定によるセキュア
OS
の性能評価
松田 直人
†
田端 利宏
†
宗藤 誠治
‡
†岡山大学 大学院自然科学研究科 700-8530岡山県岡山市津島中3–1–1 [email protected] [email protected] ‡日本アイ・ビー・エム東京基礎研究所 242-8502神奈川県大和市下鶴間1623–14 [email protected] あらまし システムの脆弱性の悪用により，企業システムや個人用計算機が様々な被害を受ける問 題が起こっている．この問題を解決する手段として，セキュアを用いる方法が有効である．しか し，その実現方式と性能について語られることは少ない．このセキュアOSの機能は，Linux 2.6以降では，Linux Security Modules（LSM）により実装される場合が多い．そこで，我々は，LSM
のオーバーヘッド測定のための機能拡張をLinuxカーネルに行い，代表的な4つのセキュアOSの 性能評価を行った．本論文では，ベンチマークソフトによる各セキュアOSのオーバーヘッドと， 各LSMフックでのオーバーヘッドの分析結果について述べる．
An Evaluation of Performance of Security Focused OS
by Measuring the Overhead of LSM
Naoto Matsuda
†
Toshihiro Tabata
†
Seiji Munetoh
‡
†Graduate School of Natural Science and Technology, Okayama University
[email protected] [email protected]
‡IBM Tokyo Research Laboratory
Abstract Enterprise systems and individuals suffer from various attacks because of exploiting
vulnerabilities of the systems. As a method resolving this problem, security focused operating system (OS) is an effective way. However, the performance of security focused OS has little chance to talk about. In Linux 2.6, since the function of security focused OS is implemented using Linux Security Modules (LSM), we have extended the function to measure the overhead of the LSM, and evaluated the performance of four typical security focused OS. In this paper, we describe the result of analysis of the overhead of security focused OS and the LSM hooks.
1
はじめに
システムの脆弱性の悪用により，企業システ ムや個人用計算機が様々な被害を受ける問題が 起こっている．特に，root権限が奪取されてし まうと，その被害は甚大なものとなってしまう． しかしながら，ファイアウォールやIDSなどを 用いた従来の方法で，これらの攻撃をて防ぐの は非常に難しい．また，ゼロデイ攻撃への対処 も難しい． これらの問題を解決する手段として，セキュ アオペレーティングシステム（OS）を用いる 方法が有効である．セキュアOSは，強制アクセス制御（MAC）機能を提供することで，た とえroot権限が奪取されたとしても，被害を ポリシで許可された範囲内にとどめることがで きる．Linux1におけるセキュアOSは，Linux 2.6 にて追加された機能であるLinux Security Modules（LSM）[1]により，実装される場合が 多い．その実装例として，Security-Enhanced Linux（SELinux）[2]やAppArmor[3]などがあ る． これらのセキュアOS間には，実装方式や資 源の識別方式の違いによるセキュリティ特性に ついて，比較がなされている．しかしながら， その性能について語られることは少ない．シス テムとそれに対する脅威は高度化・複雑化して いるため，新たな脅威への対抗策としても，セ キュアOSは有効である．しかし，実際のシス テムでセキュアOSを使用する場合には，その 性能を把握することが必要不可欠である． そこで，我々は，LSMのオーバーヘッド測定 機能であるLSM Performance Monitor（ LSMP-MON）をLinuxカーネルに実装した． LSMP-MONは，各LSMのフック箇所での処理時間と 呼び出し回数を記録することで，セキュアOS 間での性能比較を容易に行うことが可能である． 本稿では，このLSMPMONの実現方式と，本 機能を用いたセキュアOSの評価結果について 述べる．
2
技術背景
2.1
セキュア OS
2.1.1 概要 セキュアOSは，一般的に，強制アクセス制 御（MAC）と最小特権を実現する機能を備えた OSのことを指す．多くのOSで用いられている 任意アクセス制御（DAC）では，各ファイルの 所有者が独自にアクセスパーミッションを設定 できる．また，UNIXにおけるrootやWindowsにおけるAdministratorのようなスーパーユー
ザ権限を持つユーザは，DACのチェックをバ イパスして全ての資源にアクセス可能である． このため，悪意のあるユーザによってスーパー
1Linuxは、Linus Torvaldsの米国およびその他の国
における商標． /usr/sbin/httpd ラベル: httpd_t ino: 123 プロセス /var/www/index.html ラベル: web_contents_t ino: 456 資源 read /usr/sbin/httpd ラベル: httpd_t ino: 123 プロセス /var/www/index.html ラベル: web_contents_t ino: 456 資源 read 図1 WebサーバによるWebページの読み込み ユーザ権限が奪取されてしまうと，その被害は 甚大なものとなってしまう． 一方，MACを用いると，セキュリティポリシ によって許可された資源への許可された操作の みに行動が限定される．これは，スーパーユー ザ権限を持つユーザにも強制されるため，不正 アクセス等によりスーパユーザ権限を得たとし ても，その行動を制限できる． セキュアOSのうち，対象OSがLinuxであ り，かつ，オープンソースで開発されている代 表的なものとして，SELinux, AppArmor, TO-MOYO Linux[4]，及びLIDS[5]がある．これら のセキュアOSの特徴と資源の管理方法の違い を，Webサーバ（httpd）によるWebコンテン ツの読み込み（図1）を例に挙げて以降で説明 する． 2.1.2 SELinux SELinuxは，米国家安全保障局によって開発 されているセキュアOSであり，Linuxカーネル に標準で組み込まれている唯一のセキュアOS である．SELinuxは，資源の識別方式にラベル を用いており，図1の例では，httpd tというラ ベルを付与されたプロセスが，web contents t ラベルを付与されたファイルの読み込みを行う と解釈される． 2.1.3 AppArmor AppArmorは，米Novell社を中心に開発さ れているセキュアOSである．資源の識別には， パス名を用いており，/usr/sbin/httpdが， /var/www/index.htmlの読み込みを行うと解 釈される． 2.1.4 TOMOYO Linux TOMOYO Linuxは，NTTデータによって 開発されているセキュアOSである．資源の識 別には，AppArmorと同様にパス名を用いてい る．また，プロセスの識別には，パス名とその
AP (2) DACチェック (3) LSMフック ユーザ空間 カーネル空間 (1) (4) セキュアOSの MACチェック (5) システムコール処理 AP (2) DACチェック (3) LSMフック ユーザ空間 カーネル空間 (1) (4) セキュアOSの MACチェック AP (2) DACチェック (3) LSMフック ユーザ空間 カーネル空間 (1) (4) セキュアOSの MACチェック (5) システムコール処理 図2 LSMの構造 プロセスがどういった経路で実行されたかとい う履歴を使用している．例えば，同じhttpdで あっても，OS起動時にカーネルによって起動 されたhttpdと，ユーザがシェルから起動した httpdに対して，異なるポリシを付与すること ができる． 2.1.5 LIDS
LIDSは，Xie Huangang氏とPhilippe Biondi
氏によって開発されたセキュアOSである．LIDS は，アクセス制御の設定にはパス名を用いてい る．一方，内部的には，iノード番号を用いて資 源の管理を行っている．しかし，iノード番号に よる管理には問題がある．viやemacsなどの多 くのテキストエディタは，ファイルの編集のた めに一時ファイルを作成し，データの変更はそ の一時ファイルに対して行われる．そして，変 更を保存する際には，一時ファイルで元のファ イルを上書きする．これにより，ファイル名は 同じであるが，iノード番号の違うファイルが できてしまうため，正しいアクセス制御を行う ことができなくなってしまう．
2.2
LSM
LSMは，カーネル内のセキュリティチェック 機構へのフック関数群を定義する機能である． Linux 2.6以降では，LSMがカーネルに組み込 まれており，セキュアOSの機能は，LSMによ り実装される場合が多い．LSMの構造を図2に 示し，以下に説明する．アプリケーションプロ グラム（AP）がシステムコールを発行すると， 最初に，DACによるセキュリティチェックが行 われる．次に，カーネル内のセキュリティチェッ AP DACチェック LSMフック システムコール処理 セキュアOSの MACチェック LSMPMON securityfs 時刻とフック箇所の情報を取得し， 結果を比較，保存する 制御，結果の取得 AP AP DACチェック LSMフック システムコール処理 セキュアOSの MACチェック セキュアOSの MACチェック LSMPMON securityfs 時刻とフック箇所の情報を取得し， 結果を比較，保存する 制御，結果の取得 AP 図 3 LSMPMONの構造 ク箇所（Linux 2.6.19現在，163箇所）で，登録 されたLSMのフック関数が呼び出され，各セ キュアOSによりセキュリティチェックが行わ れる．これらのチェックで操作が許可された場 合のみ，実際のシステムコール処理が行われる．3
LSMPMON
3.1
目的
セキュアOSを実際のシステムで使用する場 合，その性能を把握することが必要不可欠であ り，システムに適したセキュアOSの選択には 細かな性能比較が必要である．セキュアOSの セキュリティチェック機能は，LSMフック関数 中で呼び出される．よって，セキュアOSの性能 評価を行うには，LSMフック関数の性能評価を 行えばよいことがわかる．そこで，LSMのオー バーヘッド測定機能であるLSM Performance Monitor（LSMPMON）をLinuxカーネルに実 装した．3.2
実現する機能
性能測定のために最低限必要な要件は，フッ ク関数の処理時間と呼び出し回数の測定を漏れ なく行えることである．また，本機能に求めら れる要望として，動作の制御と結果の取得が容 易であり，測定機能のオーバーヘッドが小さい ことが挙げられる．3.3
実装
我々は，LSMPMONをLinux 2.6.19.7に実 装した．このLSMPMONの構造を図3に示す． LSMPMONは，全LSMフック関数の呼び出し表1 各セキュアOSの比較
SELinux AppArmor TOMOYO LIDS
LSMフック数 149 39 17 38 資源の識別方式 ラベル パス名 パス名+ 実行履歴 iノード バージョン 2.4.6-80.fc6 March 07 v405 2.0 2.2.3rc1 表2 LSMPMONのオーバーヘッド（単位:sec） 有効時 無効時 ApacheBenchの実行時間 0.357 0.348 前後での時刻を取得し，対象のLSMフック関 数の処理時間を測定する．セキュアOSの全て のセキュリティチェックは，LSMフック関数を 通して行われる．よって，漏れなく測定を行え るため，機能要件を満たしているといえる， 機能要望であるユーザインタフェースの簡易 化には，securityfsを用いることによって対応 した．securityfsは，セキュリティモジュール用 の特殊な仮想ファイルシステムであり，ユーザ 空間とカーネル空間でのデータのやり取りを簡 易に行うことができる． LSMPMONの動作例を図4に示す． security-fsを用いることで，ユーザ空間とカーネル空間 でのデータの授受をechoやcatのような既存の APを用いて行えることがわかる．表示する情報 は，各LSMフック関数の最短処理時間（min） と最長処理時間（max），平均処理時間（ave） 及び呼び出し回数（count）である．これらの情 報を用いることにより，セキュアOS間の性能 比較だけでなく，ボトルネック箇所の把握も可 能であるため，開発時にも有用である． LSMPMONの基本オーバーヘッドを表2に示 す．性能測定には，ApacheBenchを用い，ファ イルの読み込み要求を100回行ったときの実行 時間を示している．この結果より，LSMPMON のオーバーヘッドは，約2.5%と小さい． 以上のことより，簡易なユーザインタフェー スの実現と，機能の軽量化という機能要望を満 足しているといえる． LSMPMON有効化 % echo 1 > /sys/kernel/security/lsmpmon/control LSMPMON無効化 % echo 0 > /sys/kernel/security/lsmpmon/control 結果を表示 % cat /sys/kernel/security/lsmpmon/result hook min max ave count ---. . . inode_create 97 1818075 105 3035605 inode_link inode_unlink 97 80903 114 3035600 . . . 図 4 LSMPMONの動作例
4
評価
4.1
概要
我々は，LSMPMONを用いて，SELinux, AppArmor, LIDS, 及びTOMOYO Linuxの性 能評価を行った．性能評価にはLMbench[6]を 用い，ファイル操作におけるセキュアOSのオー バーヘッドと，主要なファイル操作時にセキュ リティチェックを行うLSMフック関数のオー バーヘッドについて評価を行った．4.2
評価内容
評価は，CPU: Intel Pentium 4 (3.0GHz)，メ モリ: 1GB, OS: Linux 2.6.19.7の計算機上で 行った．評価対象として，セキュアOSを使用 しない場合（None）と2章で挙げた4つのセ キュアOSを用い，以下の2点について評価を 行った． 評価（1）LMbenchによるオーバーヘッド比較 ベンチマークソフトLMbenchを使用し， その中でも特にファイル操作に関する結 果を評価する．測定は5回行い，その平 均処理時間を示す．
評価（2）LSMPMONによるLSMフック関数 のオーバヘッド比較 ファイル操作時にセキュリティチェックを 行うLSMフック関数のオーバーヘッドを LSMPMONを用いて評価する．測定には LMbenchを5回実行し，その平均処理時 間を示す． なお，各セキュアOSの資源識別方式とLSM フック箇所数，セキュアOSのバージョンは，表 1のとおりである．
4.3
測定結果
評価（1）の結果を表3に示す． SELinuxにおけるstatの処理時間は，約58% 増加している．ファイル処理のうち，最も多用 されるものはstatであり，その割合は約40%で あるという調査結果もある[7]．このため，シス テム全体のオーバーヘッドも大きくなる可能性 が高い． ファイルの生成時間に着目すると，SELinux の処理時間増加率が最も高い．このため，大量 のファイル生成が起こるメールサーバなどの用 途では注意が必要である．しかし，より多くの ディスクアクセスが必要になる10KBのファイ ル生成では，処理時間増加率は低下するため， サイズの大きいファイルを扱う場合には，その 影響は小さいと考えられる． 評価（2）の結果を表4に示す．なお，表4中 の“N/A”は，対象のフック関数が実装されて いないことを表す． 処理時間が1,000クロックサイクル未満もの は，主にポリシの探索のための時間である．SELinuxは，inode createの処理時間が非常に 長い．これは，新たに作成されるiノードに対 して，ラベル付けを行う必要があるためである．
AppArmorは，inode createとinode unlink処 理に，他の処理の約10倍の時間を要している． これは，パス名の取得が必要なためと考えられ る．TOMOYO Linuxは，inode permission処 理とその他場合に要する時間では，約20倍の 差がある．これは，inode permission以外の処 理時に，セマフォ獲得の必要があるためである． 一方，LIDSは，iノード番号によって資源の 管理を行っているため，ポリシの探索を高速に 行うことができる．よって，LSMフック関数の 処理時間は，比較的短いものになっている． 次に，表3中の各処理で呼び出されるLSM フック関数のうち，表4に含まれるものの関数 名と呼び出し回数を表5に示す．ただし，LSM フック関数の処理時間とその呼び出し回数は， システムコールのオプション等によって異なる． 表3，4，5より，これらの間には，相関関係が あることが分かる．SELinuxの0K file create
は，非常に低速である．この理由は，file cre-ateの処理中に呼び出されるinode createの処 理が低速なためである．TOMOYO Linuxは，
open/closeの処理時間増加率が非常に高い．こ
れは，ファイルopen時のinode permissionの 処理時間は，約1.76µsecと，平均値よりも非常 に大きくなっているためである．しかし， TO-MOYO Linuxは，readやwriteといったファイ ルopen後の操作でセキュリティチェックを行っ ていない．このため，10KBのファイル生成処 理時間の増加率は小さくなっている．
4.4
まとめ
ラベルによる識別を行うSELinuxは，ラベル 付けを行う必要があるため，ファイル生成時の オーバーヘッドが大きく，ファイル生成時以外 のオーバーヘッドも，比較的大きい．また，設 定工数が多く，設定内容が複雑で理解しにくい という問題もある．しかし，粒度の細かいアク セス制御設定が可能であることや，情報フロー の分析を確実に行えるというメリットがある． パス名による識別を行うAppArmorと TO-MOYO Linuxは，パス名の取得が必要な場合 のオーバーヘッドが大きくなる．また，情報フ ロー分析が困難である．しかし，パス名を用い ることにより，設定が分かりやすく，ポリシの 自動生成にも有利である． iノードによる識別を行うLIDSのオーバー ヘッドは，比較的小さい．しかし，iノード番号 が変化する場合に問題が発生するため，対処が 必要である．5
おわりに
LSMのオーバーヘッド測定機能である LSMP-MONの実装と，本機能を用いたセキュアOSの表3 ファイル操作時の処理時間と増加率（単位:µsec）
None SELinux AppArmor TOMOYO LIDS
stat 1.67 2.65 ( 58%) 1.87 (12%) 2.02 ( 21%) 2.17 (30%) open/close 2.49 3.62 ( 45%) 4.16 (67%) 8.76 (252%) 3.27 (31%) 0K file create 9.67 25.92 (168%) 14.16 (47%) 16.00 ( 66%) 13.90 (44%) 0K file delete 5.58 8.61 ( 54%) 8.03 (44%) 9.88 ( 77%) 6.68 (20%) 10K file create 36.82 51.86 ( 41%) 40.30 ( 9%) 41.50 ( 13%) 39.38 ( 7%) 10K file delete 15.82 19.66 ( 24%) 19.44 (23%) 21.40 ( 35%) 18.62 (18%) 表4 ファイル操作時のLSMフック関数の処理時間（単位:µsec）
None SELinux AppArmor TOMOYO LIDS
inode create 0.035 4.411 1.701 3.047 N/A
inode unlink 0.038 0.270 1.523 2.803 0.096
inode permission 0.034 0.152 0.110 0.142 0.156
inode setattr 0.041 0.285 0.261 2.899 0.152
inode getatttr 0.035 0.124 0.035 N/A N/A
file permission 0.037 0.044 0.200 N/A 0.040
表5各ファイル操作時に呼び出されるLSMフッ ク関数とその呼び出し回数
LSMフック関数 回数
stat inode permission 2
inode getattr 1 open/close inode permission 3 file create inode permission 4
inode create 1
inode setattr 1 file permission 1 file delete inode permission 2
inode unlink 1 評価について述べた．具体的には，Linuxにお けるセキュアOSの実装方式について説明し， そのオーバーヘッドを測定する方法について述 べた．測定機能をLinux上へ実装し，4つのセ キュアOSについて評価を行った．評価の結果， セキュアOSの実装方式により，性能に大きな 差があることを確認した． 今後の課題として，他のLSMフック関数の オーバーヘッド比較と，オーバーヘッドの詳細 な分析，及びLSMPMONの機能拡充がある． 謝辞 本研究の一部は，C&C振興財団 若手研究 員助成，及び科学技術振興機構戦略的国際科学 技術協力推進事業の支援を受けて行った．
参考文献
[1] C. Wright, C. Cowan, J. Morris, S. Smal-ley, G. Kroah-Hartman, “Linux Security Modules: General Security Support for the Linux Kernel,” Proceedings of 11th Annual USENIX Security Symposium, pp 17–31, 2002.
[2] P. Loscocco, S. Smalley, “Integrating flex-ible support for security policies into the Linux operating system,” Proceedings of the FREENIX Track: 2001 USENIX Annual Technical Conference (FREENIX ’01), pp 29– 42, 2001. [3] Novell, AppArmor, http://www.novell.com/linux/security/ apparmor/ [4] 原田 季栄，保理江 高志，田中 一男，“使い こなせて安全な Linux を目指して，” Linux Conference 2005. [5] LIDS, http://www.lids.org/ [6] LMbench, www.bitmover.com/lmbench/ [7] D. Roselli, J. R. Lorch, T. E. Anderson, “A
Comparison of File System Workloads,” Pro-ceedings of 2000 USENIX Annual Technical Conference, pp. 41–54, USA, June, 2000.
