all about selinux

1章◆SELinuxとは？／中村雄一／才所秀明 ..................................................................................................222章◆これで完璧！ SELinuxのインストール／基本操作／才所秀明 ..................................................333章◆SELinux設定方法の基礎～ポリシファイル編集法／中村雄一...................................................404章◆SELinux徹底活用セキュアなWebサーバ構築＆管理マニュアル／中村雄一...........................51Appendix①◆セキュリティの基礎はここからLSMを理解する／中村雄一..............................................59Appendix②◆SELinuxの最新動向／中村雄一........................................................................................645章◆他のセキュアOSの選択肢～LIDSの紹介／面和毅 .............................................................................68Appendix③◆FreeBSDのセキュリティ機能～jailの紹介／籠谷和男...............................................79

SELinuxとは，アメリカのNSA（National

Security Agency，国家安全保障局）を中心として

開発された，オープンソースのセキュアOSです．

とは言っても，SELinuxというディストリビューシ

ョンがあるわけではなく，Linuxカーネルのセキュ

リティ強化モジュールの名称です．SELinuxは，

OSのパーミッションチェックを大幅に強化し，プ

ロセス／ユーザを最小限の権限で動作させます．

攻撃者が不正侵入したとしても大きな権限を得る

ことができないため，被害を与えることは極めて

困難です．

SELinuxは，Linuxカーネル2.6の標準オプション

として採用され，ディストリビューションでの対

応も進んでいることもあり，注目を集めています．

現在のところ，Fedora Core 2ではSELinuxが完全

に取り込まれています．

そもそも，なぜSELinuxのようなものが必要に

なるのでしょうか？その背景としては，Linuxと

いうOS自体の脆弱性が挙げられます．

コンピュータをひとたびネットワークに接続す

ると，さまざまな不正アクセスにさらされます．

不正アクセスの手順は図1のようになります．

①攻撃者は，セキュリティホールを突いてデーモ

ンを乗っ取ったり，ユーザになりすましたりす

ることで，システムに侵入し，システムのアク

セス権限を得ます．

②侵入段階で得たアクセス権限を悪用し，悪意の

あるアクセス要求を行います．たとえば，重要

データに対する書き込み／読み込みアクセスな

どです．

③悪意のあるアクセス要求が実行され，データが

22 - Software Design

導入部となる本章では，SELinuxの基本について解説します．後半部では，SELinuxのしくみなど，技術的な側面を取り上げます．

日本SELinuxユーザ会準備委員会中村雄一 NAKAMURA Yuichi ●[email protected]日立ソフトウェアエンジニアリング㈱才所秀明 SAISHO Hideaki ● [email protected]

特集●SELinux大全

SELinuxの基本●中村雄一 NAKAMURA Yuichi E-mail : [email protected]

SELinuxとは？

現在のSELinux採用状況

Linuxの脆弱性

Linuxの脆弱性

盗難／破壊されます．その結果，Webページ改

ざん，システム破壊，バックドア／トロイの木

馬の設置など，さまざまな被害が発生します．

●root権限を取られると

しかし，LinuxはOSとしては，このような不正

アクセスに対して十分な機能を提供していません．

Linuxには万能のroot権限が存在するため，ひとた

び root権限を取られると，非常に大きな被害を受

けてしまいます．

たとえば，sshデーモンはroot権限で動作してい

るため，sshデーモンにセキュリティホールがある

と，攻撃者は root権限を得ることができます．こ

うなると攻撃者は root権限を悪用し，やりたい放

題になってしまいます．

●「SUID=0」の脆弱性

最近のLinuxのデーモンは，一般ユーザ権限で動

作することが多くなっています．しかし，SUID=0

のプログラムを使って root権限に昇格する抜け道

が存在するため，一般ユーザ権限を取られただけ

でも危険です．

SUID=0のプログラムは，root権限で動作します注1．

もし，このようなSUID=0のプログラムにセキュリ

ティホールがあると，一般ユーザからrootユーザに

昇格することができてしまいます．

このような不正アクセスを阻止するために，さ

まざまな対策が試みられています．主要な不正ア

クセス対策を，図2に示します．ネットワーク／ア

プリケーション／OSそれぞれのレベルでの対策が

存在します．

ファイアウォール，IDS，パッチ当てといった，

ネットワーク／アプリケーションレベルの対策は，

図2の「①侵入」の段階で防御する対策です．しか

し，侵入の原因となるセキュリティホールは次々

と発見されますので，これらすべてに対処するこ

とは事実上不可能です．1つでも対策を忘れ，そこ

から root権限を取られてしまうと，大きな被害を

こうむってしまいます．

このように，いくらセキュリティに配慮したシ

ステムを構築しても，脆弱なOSの上ではたった1

つのほころびから大きな被害につながります．

そこで重要になってくるのは，OSレベルのセキ

ュリティ対策，つまりSELinuxのようなセキュア

Oct. 2004 - 23

1章◆SELinuxとは？

注1）SUID=0のプログラムの例としては，passwdコマンドがあります．passwdコマンドはroot権限で動作しますので，本来rootユーザ

でしか扱えないパスワードファイルを，一般ユーザでも編集することができます．

攻撃者

アプリケーション

データ

ネットワーク

✗

Linuxマシン

OS （カーネル）

ネットワークレベルの対策ファイアウォール，IDSなど

アプリケーションレベルの対策パッチ当てなど

OSレベルの対策 SELinuxのようなセキュアOS

①侵入

②悪意のあるアクセス要求

③盗難／破壊

●図2 不正アクセス対策

①侵入攻撃者

アプリケーション

データ

ネットワーク

✗

Linuxマシン

OS （カーネル）

②悪意のあるアクセス要求

③盗難／破壊

●図1 不正アクセスの流れ

現在のセキュリティ対策とSELinux

ネットワーク／アプリケーションレベルでの対策

SELinuxによるOSレベルでの対策

OSです．セキュアOSでは，OSのアクセス制御を

強化し，「②悪意あるアクセス要求」を拒否します．

こうしておけば，図2で「①侵入」されたとして

も，②以降の段階に進むことはできないため，攻

撃者は悪事ができません．たとえ，セキュリティ

ホールの対策を忘れたとしても効果があるわけで

す．

SELinuxのアクセス制御機能は，図3のような要

素から成り立っています．おもな要素は強制アク

セス制御と最小特権です．これらはセキュアOS注2

の基本機能でもあります．

●強制アクセス制御とは

どんなに優れたセキュリティ機能でも，その機

能の利用を徹底できなければ意味がありません．

強制アクセス制御は，アクセス制御の設定をシス

テム全体に徹底させるための機能です．

従来のLinuxのアクセス制御モデルである「任意

アクセス制御（DAC： Discretionary Access

Control）」では，ファイルの所有者がパーミッショ

ンの設定を行います．そのため，ファイルのセキ

ュリティは所有者任せです．また，rootユーザは

パーミッションチェックを回避可能です．このよ

うな状況では，セキュリティの設定を徹底させる

ことは困難です．

それに対して強制アクセス制御（MAC：

Mandatory Access Control）では，プロセスがどん

なリソースにアクセスできるか，といったアクセ

ス制御の設定は「ポリシファイル」と呼ばれる設

定ファイルで集中管理されます．ポリシファイル

の編集は，セキュリティ管理者のみが行うことが

できます．そしてその設定は，すべてのプロセ

ス／ユーザに例外なく適用されます．これにより，

セキュリティ管理者が定めたセキュリティの設定

を徹底することができます．


注2）セキュアOSの意味については，コラムを参照してください．

●セキュアOSの定義

セキュアOSは，OSレベルでセキュリティを強化する

もので，オープンソース／商用とさまざまなものがリリー

スされています．情報ネットワーク法学会に所属するセキ

ュアOS研究会（http://in-law.jp/secure-os/）で策定中の

「セキュアOS」の定義によると，「強制アクセス制御およ

び最小特権という2つの機能を備えたOS」とされていま

す．

●各セキュアOSの違い

最小特権の詳しい実装は，セキュアOSの種類によって

特徴が出てくるところです．一般に，より細かく権限を

細分化できるほどセキュリティは高いですが，セキュリテ

ィポリシの設定が面倒になってきます．今回紹介する

SELinuxとLIDSというセキュアOSを例にとると，

SELinuxはセキュリティ重視で，LIDSは扱いやすさ重視

という特徴があります．

●商用のセキュアOSについて

また，商用セキュアOSでは，強制アクセス制御／最小

特権という基本機能以外に，侵入を防止するための機能

を備えていることもあります．たとえば，バッファオーバ

ーフロー攻撃という侵入段階でひんぱんに用いられる攻撃

を防御する機能を備えているものが多いです．

なお，バッファオーバーフロー攻撃防御のための機能

は，無償のものでもexec-shieldというものがあり，Fedora

Core 2ではSELinuxに同梱されています．

セキュアOSとは

COLUMNCOLUMNCOLUMNCOLUMNCOLUMNCOLUMNCOLUMNCOLUMNCOLUMN


TE RBAC ドメイン遷移

セキュアOSとしての基本機能

強制アクセス制御（MAC）

最小特権

監査ログ

●図3 SELinuxの機能構成要素

●最小特権とは

従来のLinuxでは，root権限が全権を掌握してい

るため，root権限を取られてしまうとおしまいで

す．SELinuxでは，rootのような絶対の権限をなく

し，プロセスやユーザに必要最低限の権限を割り

当てます．これを最小特権と呼びます．

たとえば，Webサーバ Apacheに対しては，

「httpd_tドメイン」という独自の権限を割り当て，

ホームページへの読み込み権限のみを与え，関係

ないファイルへのアクセスはできないよう，セキ

ュリティポリシに記述します．これらの権限は，

普通のLinuxの一般ユーザ権限よりもはるかに小さ

な権限です．こうしておけば，たとえばApacheに

セキュリティホールがあり，侵入を許したとして

も，攻撃者はApache権限しか得ることができない

ため，実質的な被害を及ぼすことはできません．

SELinuxの最小特権は，TE／RBAC／ドメイン

遷移という機能によって実現されています．以下，

これらの機能を含め，SELinuxの機能の詳細につい

て解説します．

Oct. 2004 - 25


では，強制アクセス制御と最小特権およびログ

監査の機能について詳しく見ていきましょう．

SELinuxの機能概要で説明したように強制アク

セス制御は，「セキュリティ管理者のみが設定でき

るセキュリティポリシ」を「すべてのユーザ／プ

ロセスに強制する」ことです．SELinuxでは，

LSM（Linux Security Module：図4の③）を利用す

ることで，「すべてのユーザ／プロセスに強制する」

ことを実現しています．

LSMを簡単に説明すると，カーネル内において，

rootでも回避できないセキュリティチェックを実

現するメカニズムです注3．SELinuxはセキュアOS

モジュールとして，「セキュリティ管理者のみが設

定できるセキュリティポリシ」と，そのセキュリ

ティポリシに従ったセキュリティチェックを実装

しています．

最小特権はTE（Type Enforcement）とドメイン

遷移，RBAC（Role-Based Access Control）で実現

されています．これらについて順に説明していき

ます．

SELinuxの機能詳細●才所秀明 SAISHO Hideaki E-mail : [email protected]

注3）LSMの詳細は本特集Appendix.1を参照してください．

②Linuxパーミッション　チェック

③LSM ⑤セキュアOS 　モジュール

プロセス

①アクセス要求

④セキュリティ　チェック依頼

⑥チェック結果

⑦アクセスセキュリティポリシ

リソース

セキュリティ管理者のみが設定可能

rootでも回避できないセキュリティチェック

Linuxカーネル

●図4 LSMのしくみ

強制アクセス制御

最小特権

●基本的な考え方

最小特権の機能を実現するメインとなるのが，

プロセスごとのアクセス制御を行うTEです．図5

に，Webサーバとしてよく使われるApacheを例と

したTEの概念図を示しておきます．TEの基本的

な考え方は非常に簡単で，次のようにまとめるこ

とができます．

①プロセスとリソースにラベルを付ける

②プロセスのラベルとリソースのラベルの間にア

クセス権限を設定する

③設定に基づいて，プロセスとリソースの間でア

クセス制御を行う

●用語説明

TEで利用する用語を説明します．

¡オブジェクトクラスとアクセスベクタ

通常のLinuxでは，アクセス権限を設定できるリ

ソースはファイルとディレクトリだけでしたが，

SELinuxではソケットや共有メモリなど，約30種

類のリソースに対してアクセス権限を設定できる

ようになっています．

その際，設定可能なアクセス権限の種類は，リ

ソースの種類によって異なるはずです．たとえば，

ファイルにはreadやwriteなどのアクセス権限が考

えられますが，ソケットにはconnectや listenとい

うアクセス権限の設定が必要となるでしょう．

SELinuxでは，リソースの種類ごとに，オブジェ

クトクラスと呼ばれるものが定義されています．

また各オブジェクトクラスには，設定可能なアク

セス権限が定義されています．このアクセス権限

はアクセスベクタと呼ばれます．

では，このオブジェクトクラスとアクセスベク

タの定義の実例を見てみましょう．オブジェクト

クラスとアクセスベクタの定義は，「/etc/security/

selinux/src/policy/flask」以下のsecurity_classesフ

ァイルとaccess_vectorsファイルにあります注4．フ

ァイルに関連するオブジェクトクラスの一部をリ

スト1に示します．ファイルやディレクトリのクラ

スは，ファイル関連の共通設定を継承していて，

多くのアクセスベクタが定義されています．

通常の Linuxでは，ファイルに対して read，

write，executeの3つしかアクセス権限を設定でき

ませんでした．しかしSELinuxでは，リスト1のよ


プロセス（サブジェクト）

パーミッション（アクセスベクタ）

リソース（オブジェクト）

httpdプロセス /var/www/

read

ドメイン： httpd_t

タイプ： httpd_sys_content_t

②アクセス権限の設定

①ラベル付け

③アクセス制御

●図5 Apacheを例としたTEの概念図

注4）本章で解説しているファイルの位置などは，Fedora Core 2でpolicy-sourceパッケージをインストールしている場合です．インスト

ール方法は本特集2章で説明します．

common file{

ioctlreadwritecreategetattrsetattrlockrelabelfromrelabeltoappendunlinklinkrenameexecuteswaponquotaonmounton

}

class dirinherits file{

add_nameremove_namereparentsearchrmdir

}

class fileinherits file{

execute_no_transentrypoint

}

●リスト1 オブジェクトクラスとアクセスベクタの定義例（access_vectors）

←ファイル関連（共通の設定）

←ファイル関連共通のアクセスベクタ

←ディレクトリのクラス←ファイル関連共通設定を継承する

中略

←ディレクトリのアクセスベクタ

←ファイルのクラス←ファイル関連共通設定を継承する

←ファイルのアクセスベクタ

TEについて

うに追記だけを許可するappendなど，さまざまな

アクセス権限が設定可能となっています．このよ

うに，SELinuxではフレキシビリティの高いアクセ

ス権限設定が可能となっています．

¡ドメイン

プロセスに対して付けるラベルはドメインと呼

ばれます．SELinuxでは，すべてのプロセスにドメ

インが付けられています．「基本的な考え方」の項

で説明したように，ドメインとリソースに付けら

れたラベルの間にアクセスベクタを設定し，その

設定を元にアクセス制御が行われます．したがっ

て，ドメインを権限の単位そのものと考えること

もできます．

図5ではApacheのプロセスである「httpd」に対し，

「httpd_t」というドメインが付けられています．プロ

セスにドメインを付ける設定方法については，のち

ほど「ドメイン遷移について」の項で説明します．

¡タイプ

リソースに付けるラベルはタイプと呼ばれます．

SELinuxでは，このタイプによってリソースを識別

し，先に述べたオブジェクトクラスと併せて，ア

クセス制御を行っています．

図5では，公開したいhtmlファイルを含むディ

レクトリ「/var/www/」に「httpd_sys_content_t」

というタイプが付けられています．

リソースへのタイプ付けの設定方法は，オブジ

ェクトクラスによって異なります．ここでは，最

もわかりやすいファイル／ディレクトリのタイプ

付けの実例を見てみましょう．

ファイル／ディレクトリのタイプ付け設定は，

「/etc/security/selinux/src/policy/file_contexts」以下

の「*.fc」ファイルで行われます．たとえば，リスト

2はApacheに関連するファイル／ディレクトリの設

定の一部です．リスト中の枠囲み部分で，

「/var/www/」の設定が行われています．タイプ付け

設定の変更については，あとで詳しく説明します．

●設定記述方法

さて，今まで解説してきた用語を用いて「基本

的な考え方」の箇条書き部分を書き直すと，以下

のようになります．

qプロセスにドメインを，リソースにタイプを付

ける

wドメインとタイプの間でアクセスベクタを設定

する

qについては用語説明の中で触れましたので，

wについて実際の記述方法を見てみましょう．図5

の設定はリスト3のような記述で行います．

これは「ドメインhttpd_tを付けられたプロセス

に対し，オブジェクトクラス fileまたはdirでタイ

プhttpd_contents_tを付けられたリソースへ，アク

セスベクタreadの権限を与える」という意味です．

このような設定は，「/etc/security/selinux/src/

policy/domains」以下の「*.te」ファイルで行われ

ます．

Oct. 2004 - 27


allow httpd_t httpd_contens_t:{ file dir } { read }

●リスト3 TE設定記述の例

ドメインタイプオブジェクトクラスアクセスベクタ

# apacheHOME_DIR/((www)|(web)|(public_html))(/.+)? system_u:object_r:httpd_ROLE_content_t/var/www(/.*)? system_u:object_r:httpd_sys_content_t/var/www/cgi-bin(/.*)? system_u:object_r:httpd_sys_script_exec_t/usr/lib(64)?/cgi-bin(/.*)? system_u:object_r:httpd_sys_script_exec_t/var/www/perl(/.*)? system_u:object_r:httpd_sys_script_exec_t/var/cache/httpd(/.*)? system_u:object_r:httpd_cache_t/etc/httpd -d system_u:object_r:httpd_config_t/etc/httpd/conf.* system_u:object_r:httpd_config_t

●リスト2 ファイルのタイプ付け定義例

/var/www(/.*)? system_u:object_r:httpd_sys_content_t

●設定の特徴

SELinuxでは，上記のように「ドメインに対して

リソースへのアクセス権限を与える」という設定

を行っていきます．逆に，設定されていないアク

セスはすべて許されません．このため，セキュリ

ティ管理者がセキュリティ設定を忘れたりサボっ

たりしても，セキュリティ上問題になることはあ

りません．ただし，必要な設定を行わないとプロ

セスが動作しなくなります．

セキュリティ設定を忘れるとプロセスが動作し

ないという特徴は，やや面倒に思われるかもしれ

ません．しかし，セキュリティの観点から言えば，

安全でない設定が行いづらければ，結果として安

全な設定になるので，良い特徴と言えます．

●必要性

ドメイン遷移は，プロセスにドメインを割り当

てるメカニズムです．ドメインを権限の単位と考

えれば，プロセスに権限を割り当てるメカニズム

と言っても良いでしょう．

SELinuxでは，あるプロセスが別のプロセスを起

動する際，基本的に起動元のプロセスと同じドメ

インが起動先のプロセスに割り当てられます．し

かし，起動元ドメインとは異なるドメインを割り

当てなければならない場合もあります．

わかりやすい例としては，OS起動時です．図6

はOS起動時に起こるプロセス起動の簡略図です．

このようにカーネル起動から次々とプロセスが起

動し，それぞれのプロセスに異なるドメインを割

り当てる必要があります．

●設定記述方法

ドメイン遷移を行うには，リスト4に示すような

記述注5を用いて，ドメイン遷移設定を行います．

これは，「ドメイン in i t rc_ tのプロセスが，

httpd_exec_tタイプの実行ファイルでプロセスを起

動した際には，起動したプロセスにhttpd_tドメイ

ンを割り当てる」という意味です．このような設

定は，アクセス権限の設定と同様に「/e t c/

security/selinux/src/policy/domains」以下の「*.te」

ファイルで行われます．

●ドメイン遷移の効果

SELinuxでは，ドメイン遷移設定を行わないとド

メイン遷移が起こりません．これはセキュリティ


カーネル kernel_t

initプロセス init_t

getty getty_t

ログインプロンプト Local_login_t

initスクリプト initrc_t

httpデーモン httpd_t

/sbin/init init_exec_t

/sbin/mingetty getty_exec_t

/etc/rc.d/rc.sysinit initrc_exec_t

/sbin/httpd httpd_exec_t

/sbin/login login_exec_t

実行ファイルタイプ

ドメイン

●図6 OS起動時のプロセス起動の簡略図

domain_auto_trans(initrc_t,httpd_exec_t,httpd_t)

●リスト4 ドメイン遷移設定記述の例

起動元のドメイン実行ファイルのタイプ遷移先ドメイン

注5）このドメイン遷移の記述は，実はマクロを利用した記述です．実際には，マクロ展開されたものがセキュリティチェックに利用されま

す．SELinuxでは，このようなマクロが数多く定義されていて，セキュリティポリシ設定では，多くのマクロを利用して設定を記述し

ます．詳細は本特集3章の「③タイプに対するアクセス許可の記述」の項を参照してください．

ドメイン遷移について

上非常に大きな意味を持っています．

従来のLinuxに対する侵入攻撃では，SUID=0の

プログラムを使って root権限に昇格する抜け道が

利用されていました．一方，SELinuxでは権限の単

位であるドメインの遷移を制限することで，この

ような権限昇格の抜け道を未然に防ぐことができ

るのです．

●RBACの必要性

ここまで説明してきたTEとドメイン遷移はプロ

セスの最小特権を実現するものでした．これに対し，

RBACはユーザの最小特権を実現するものです．

従来のLinuxでは，rootユーザがすべての管理権

限を持っていました．より正確に表現すれば，

「rootユーザは，パーミッションチェックを回避で

きるため，事実上すべての管理権限を持っていた」

ということです．このため，Webページ管理者や

グループを作成しても，rootユーザは何でもでき

てしまいました．

また，特定の管理しかしないユーザに rootユー

ザのパスワードを教えるという運用がなされ，そ

れらのユーザの操作ミスや悪意のある操作が原因

で，システム全体に被害が及んでしまうこともあ

りました．

このような運用が行われてしまう原因は，単に

セキュリティ意識が足りなかったというだけでは

ありません．これまでのユーザやグループの単位

の設定では，必要な管理権限の分割が困難もしく

は不可能だったのです．

●RBACの効果

SELinuxでは，RBACによって管理権限を完全に

分割することができます．たとえ rootユーザにな

ってもすべての管理権限を持つことはできません．

したがって，管理者のミスや悪意のある操作によ

る被害を最小化することができます．

●RBACのしくみ

では，RBACのしくみについて，Web管理権限

を例に図7を用いて簡単に説明します．

①管理権限を作成

まず，Web管理者の管理権限を作成します．

RBACではこの管理権限をロールと呼びます．

たとえば W e b 管理者用のロールとして

webmaster_rを作成します．

②ユーザシェルのドメインを設定

次にそのロールに対応するユーザシェルのドメイ

ンを設定し，そのドメインに対しWeb管理に必要

な設定を行います．ドメインという用語からわか

るように，この設定はTEを用います．たとえば，

w e b m a s t a r _ t というドメインを設定し，

webmastar_tにはWeb管理に必要なリソースのタイ

プに対して必要なアクセスベクタを設定します．

③選択可能なロールを設定

さらに，ユーザ対して，選択可能なロールを設

定します．

●ユーザログイン時の動作と効果

ユーザはログイン時にロールを選択します．た

とえばWeb管理ロールであるwebmaster_rを選択

すると，webmaster_rに対応したユーザシェルが起

動します．

Oct. 2004 - 29


Web管理ロール webmaster_r

ユーザ saisho

webmaster_t ドメイン

③ユーザが選択可能なロールを設定

qログイン時にロール選択

①Web管理者用のロールを作成

wロールに応じたユーザシェル起動

ユーザシェル

②(a)webmaster_rに対応する　　ユーザシェルのドメインを設定 ②(b)Web管理に必要なアクセス権限を設定

●図7 RBACの実例

RBACについて

このシェルには，TEを用いて必要なアクセス権

限が設定されているので，ミスや悪意のある操作

によってWeb管理に必要のないリソースに被害を

及ぼすことはできません．逆に，Web管理のみに

使われるアクセス権限，たとえばWebの設定ファ

イルへの書き込みなどは，あえて設定しない限り，

ほかのロールが持つことはありません．

また，アクセス権限設定のフレキシビリティが高

いTEを用いているため，ロールに必要な権限をきち

んと設定することができます．このためRBACによ

り，従来のLinuxとは違ってrootパスワードを複数の

人に与えるような運用を行う必要がなくなります．

TEの項で説明したように，「allow～」という記

述でアクセス設定を行っています．そして，この

アクセス設定に違反するアクセスが行われた際に

は，ログに書き出します．

リスト5はApacheを乗っ取った攻撃者がシェル

の起動に失敗したときのログです．1行目の白枠で

囲んだ部分は，execute（実行）がdenied（拒否）

されたことを示しています．2行目の枠囲み部分は，

httpdがシェルshを実行しようとしたことを示して

います．3～4行目は，httpdプロセスのドメインや，

実行しようとした実行ファイルshのタイプなどを

示しています．

このログ機能により，攻撃者の痕跡を見ること

ができます．

SELinuxでは，さらに許可されたアクセスに対し

てログを書き出すこともできます．これが監査ロ

グ機能です．

リスト6はwebmasterユーザがWebページを更

新した際のログです．1行目の枠囲み部分は，write

（書き込み）がgranted（許可）されたことを示し

ています．2行目の枠囲み部分は，書き込まれたフ

ァイルが，/var/www/html/index.htmlであること

を示しています．

3行目の枠囲み部分は，webmasterというユーザ

がwebmaster_rというロールで書き込みを行ったこ

とを示しています．4行目の枠囲み部分は，書き込

まれた/var/www/html/index.htmlのタイプとセキ

ュリティクラスを示しています．このようなログ

の書き出しは，リスト3の「allow～」という記述

と同様の形式で，リスト7の「auditallow～」とい

う記述で設定できます．

この監査ログ機能では，権限内で行われる悪意

のある操作を防止することはできませんが，ログ

が残るので抑止効果があります．

●強制アクセス制御と最小特権の効果

これまで説明してきたように，

SELinuxでは強制アクセス制御と最小

特権を実現しています．そのため，攻

撃者がアプリケーションのセキュリテ

ィホールを利用して侵入しても，攻撃

者の行動は，設定されたドメインのア


audit(xxxxxxxxxx:xxx:0): avc: denied { execute } for pid=987 exe=/usr/sbin/httpd path=/bin/sh dev=08:01 ino=962840 scontext=system_u:system_r:httpd_t tcontext=system_u:object_r:shell_exec_t class=file

●リスト5 設定違反時のログ

audit(xxxxxxxxxx:xxx:0): avc: granted { write } for pid=987 exe=/bin/vi path=/var/www/html/index.html dev=08:01 ino=962840 scontext=webmaster:webmaster_r:webmaster_t tcontext=system_u:object_r:httpd_sys_content_t tclass=file

●リスト6 監査用のログ

denied { execute }/usr/sbin/httpd /bin/sh

granted { write }/var/www/html/index.html

webmaster:webmaster_rhttpd_sys_content_t file

auditallow webmaster_t httpd_contens_t file:{ write }

●リスト7 監査ログ出力用の設定

ドメインアクセスベクタタイプオブジェクトクラス

監査ログ

アクセス違反ログ機能

監査ログ機能

SELinuxの効果と限界

SELinuxの効果

クセス権限に縛られます．

たとえばApacheのセキュリティホールを利用し

て侵入しても，先に説明したようにWebページに

readのアクセスベクタしか設定されていなければ，

Webページを改ざんされることはありません．ま

た，普通に設定すればシェルの起動すらできない

ので，ファイルなどにアクセスすることすら困難

でしょう．

●効果の実例

Slapperワーム攻撃の例（図8）を見てみましょ

う．Slapperワーム攻撃では，図中の①～⑤のステ

ップを踏んで，バックドア設置と他マシンへの攻

撃を行います．

SELinuxでは，通常の設定であればデーモンはシ

ェルやコンパイラ，未知のプログラムに対する実

行権限を持ちません．したがって，②，④，⑤の

ステップが実行できません．また，③のステップ

における書き込みを許可しない設定も可能でしょ

う．このため，Slapperワーム攻撃を受けても，

SELinuxで通常の設定を行っていれば，実際の被害

に至りません．

●監査ログの効果

また，監査ログの機能で説明したように，セキ

ュリティ設定で許可されたアクセスに対してもロ

グを取ることができます．このため，あるロール

のユーザが行う操作，たとえばWebページ管理者

によるWebページの更新などを監査することがで

き，不正な操作に対する抑止効果があります．

●効果のまとめ

このようにSELinuxは，侵入攻撃による実質的

な被害の防止やユーザの不正な操作を発見すると

いう直接的な効果があります．前者の効果により，

セキュリティホールへの対策をリアルタイムに行

わなくても良くなります．

また，最小特権が実現されているので，1つのマ

シン上でWebやDNS，メールなどのサーバアプリ

ケーションを動作させても，別々のマシン上で動

作させた場合と同等以上のセキュリティ強度を保

ちながらサーバ集約が可能となります．

しかし，SELinuxを入れればセキュリティ上万全

というわけではありません．SELinuxで対処できな

いものには，たとえば表1に挙げるようなものがあ

ります．

●アクセス制御に関係ない攻撃

SELinuxは強制アクセス制御と最小特権というア

クセス制御を実現しているに過ぎません．したが

って，アクセス制御に関係ない攻撃には何の効果

もありません．

¡バッファオーバーフロー攻撃自体

たとえばバッファオーバーフロー攻撃自体には

対処できません．あくまでバッファオーバーフロ

ー攻撃で侵入されても被害が最小になるようにア

クセス権限を設定できるだけです．しかし，バッ

ファオーバーフロー攻撃は，次で説明する権限内

Oct. 2004 - 31


①Apacheに接続，攻撃コードを送信

②シェル起動 ③/tmpに攻撃プログラム書き込み ④攻撃プログラムをコンパイル ⑤攻撃プログラムを実行

実際の被害に至らない

バックドア設置，ほかのマシンに攻撃

ワーム感染マシン Linuxマシン

…xx/bin/sh…xx… シェル起動不可書き込み制限コンパイラ実行不可攻撃プログラム実行不可

SELinuxでは…

●図8 Slapperワーム攻撃に対するSELinuxの効果

SELinuxの限界

での攻撃につながる恐れがあります．したがって，

exec-shieldなどの直接的な対策も同時に適用すべ

きでしょう．

¡DoS攻撃

また，DoS攻撃などもSELinuxで対処すること

はできません．DoS攻撃はネットワークやCPU，

メモリなどのリソースの負荷を上げ，サービスを

停止させることが目的です．リソースへの不正な

アクセスを目的としているわけではありませんの

で，基本的にSELinuxのアクセス制御で対処でき

る攻撃ではありません．このようなDoS攻撃は，

ハードウェアやソフトウェアで対策する必要があ

ります．

●与えられた権限内での攻撃

すでに説明したように，SELinuxではプロセスや

ユーザに必要最小限のアクセス権限を与えること

ができます．そのため，たとえ乗っ取られたり，

悪意のある操作が行われても，アクセス権限を越

えるような攻撃はできません．しかし，裏を返せ

ばアクセス権限内での攻撃や悪意のある操作は可

能なわけです．

¡アプリケーションの不備

たとえば，Webアプリケーションにおけるクロ

スサイトスクリプティングの脆弱性や，セッショ

ン管理不備によるなりすまし攻撃などには対処で

きません．SELinuxは，Webアプリケーションが

利用できるリソースを制限できますが，Webアプ

リケーションがそれらのリソースを正しく利用し

ているかどうかをチェックしているわけではない

のです．

このような攻撃は，与えられた権限内でリソー

スを不正に利用するものです．対策としては，セ

キュアなプログラミングを行うなどの必要があり

ます．

¡悪意のある管理者

さらに，RBACのところで説明しましたが，管理

者による悪意のある操作は，監査ログを取ることで

抑止効果を図る以上のことは望めません．したがっ

て，定期的なログ監査や管理者に対するセキュリテ

ィ教育など運用でカバーする必要があります．

●OS自体のセキュリティホール

SELinuxはカーネル，とくにLSMを基盤として

います．このため，SELinuxのセキュリティは，こ

れらに依存していると言えます．たとえば，強制

アクセス制御の基盤であるLSMのセキュリティホ

ールなどで，セキュリティチェックの回避が可能

であった場合，その攻撃にはSELinuxでは対処で

きません．したがって，OS自体のセキュリティホ

ール対策は必要不可欠でしょう．s


SELinuxでは… ほかの対策方法

■アクセス制御に関係ない攻撃

バッファオーバーフロー攻撃自体アクセス制御による被害の最小化 exec-shieldなど

Dos攻撃－ハード／ソフトウェアでの対策

■与えられた権限内での攻撃

クロスサイトスクリプティング－セキュアなプログラミング

セッション管理不備によるなりすまし攻撃－セキュアなプログラミング

管理者による悪意のある操作監査ログによる抑止セキュリティ教育や監査など

■OS自体のセキュリティホール

LSMのセキュリティホール－セキュリティパッチ

●表1 SELinuxの限界

Oct. 2004 - 33

Fedora Core 2（以下FC2）のSELinuxに関連す

るパッケージは，表1の6つです．このうち，OS

のインストールと同時にデフォルトでインストー

ルされるのは，上の4つです．デフォルトインス

トールでは，セキュリティポリシ設定の変更はで

きませんが，デフォルトのセキュリティポリシ設

定に基づいたSELinux機能を利用できます．

ただし，デフォルトインストールではSELinux

機能が無効となっています．

SELinux機能を有効にする方法を説明する前に，

SEL inux機能のモードについて説明します．

SEL inux機能には「pe rm i s s i v eモード」と

「enforcingモード」の2種類あります．

●permissiveモード

permissiveモードは，セキュリティポリシ設定に

違反するアクセスを，ログを出力したうえで実行

します．このモードは，セキュリティポリシの設

定を変更したときや，デフォルトの設定がないア

プリケーションの設定を作成したとき，アプリケ

ーションが動作しないなどの障害が発生したとき

用いられます．セキュリティポリシの変更につい

ては後で詳しく述べますが，基本的にpermissive

モードで出てきたログをベースにセキュリティポ

リシの変更を行います．

本稿では，SELinuxをFedora Core 2にインストールする方法や，SELinuxを使用するうえで理解しておくべきこと，基本的な操作方法について解説します．とくに「SELinux機能のモード」「ロール」に関しては，このあとの章でも出てきますので，しっかりと理解してください．

日立ソフトウェアエンジニアリング㈱才所秀明 SAISHO Hideaki ● [email protected]


パッケージ名解説

kernel SELinuxが組み込まれたカーネル

libselinux SELinux API

policy デフォルトのセキュリティポリシ（バイナリ形式で直接編集は困難）

policy-coreutil セキュリティポリシを扱うためのコマンド群

policy-source デフォルトのセキュリティポリシのソースファイル（テキスト形式）

checkpolicy セキュリティポリシのソースファイルをバイナリ形式に変換するツール

●表1 SELinux関連のパッケージ

デフォルトでインストールされるパッケージ

SELinux機能について

SELinux機能のモード

●enforcingモード

enforcingモードは，セキュリティポリシ設定に

違反するアクセスに対して，ログを出力してアク

セスを実行しません．あたりまえですが通常運用

時には，このenforcingモードを利用しなければ，

不正なアクセスからPCを守ることはできません．

では，SELinux機能を有効にする方法を説明し

ましょう．有効にする方法は非常に簡単で，OSイ

ンストール時に有効にする方法と，OSインストー

ル後に有効にする方法の2つがあります．

①OSインストール時に有効にする方法

インストーラ起動時に「linux selinux」と入力し

て起動します（図1）．すると「ファイヤーウォー

ル設定画面」（図2）でSELinuxのオプションを設

定できるようになります．このオプションの意味

は，「アクティブ」が「enforcingモード」に，「警

告」が「permissiveモード」に対応しています．ま

た，「ファイアウォールを無効にする」は誤訳で

「SELinuxを無効にする」が正しいです．このオプ

ションはSELinux機能を無効にしてインストール

することを意味します．とりあえず，「アクティブ」

でインストールを進めましょう．

②OSインストール後に有効にする方法

「/etc/sysconfig/selinux」ファイルにOS起動時の

SELinux機能の設定が書かれています．OSインス

トール時に有効にしていないと「SELinux=disable」

となっています．SELinuxを有効にするためには，

モードに対応して「SELinux=enforcing」もしくは

「SELinux=permissive」に変更します．

次に，ファイルのタイプ付けを行う「fixfiles

relabel」コマンドを実行し，その後リブートします．

◆◆◆

SELinux機能を次回のOS起動時から無効化する

ことも簡単です．「/etc/sysconfig/selinux」ファイ

ルで「SELinux=disable」に戻してリブートすれば

無効化します．この無効化を行うとファイルのタ

イプ付けがすべて失われます．したがって，再度

有効化を行う場合には②と同様「fixfiles relabel」

コマンドの実行も必要です．

SELinux機能の有効化は以上で完了ですが，これ

だけではX関連のタイプ付けが不十分で，Xがうま

く動作しません．そこで，再度タイプ付けを行う

には，以下の手順を踏む必要があります．

①テキストログインにします．GUIのログイン画

面でö＋ú＋!を押したり，ブートパ

ラメータを変更するなどしてください．

②rootユーザでログインします．ロールについて

は後ほど説明しますが，ここではデフォルトの


●図1 FC2インストーラの起動画面 ●図2 「ファイヤーウォール設定」画面

SELinux機能の有効化と初期化操作

SELinux機能の有効化

初期化操作

「sysadm_r」を選択してください．多くのメッセ

ージが出る場合もありますが，•で飛ばし

てしまって良いです．

③再度「fixfiles relabel」コマンドを実行します．②

の警告メッセージが操作の支障になる場合は，

ö＋ú＋#で別の端末に切り替えま

しょう．

④リブートします．

以上で，Xも正常に動作するようになります．ど

うしてもインストールがうまくいかない場合は，

カーネルのブートパラメータに「enforcing=0」と

入力してブートしてください．すると，permissive

モードでブートされます．次に「/etc/sysconfig/

selinux」ファイルの内容を確認して，「fixfiles

relabel」コマンドを実行してください．最後にリ

ブートします．

FC2では，policyパッケージによって，通常利用

に問題ない程度のデフォルトのセキュリティポリ

シ設定がなされています．そこで基本操作を説明

する前に，デフォルトのロール設定について説明

します．

FC2では「staff_r」「user_r」「sysadm_r」の3つ

のロールがデフォルトで用意されています．

「staff_r」と「user_r」は一般ユーザ用のロールで

す．ただし，「staff_r」は「user_r」が起動したプ

ロセスの停止権限など，「user_r」より強い権限を

持っています．

「sysadm_r」はシステム管理者用のロールで，ほ

とんどすべて管理が可能となっています．セキュ

リティポリシ設定の変更などシステム全体の管理

が必要な場合に利用します．

ただし，「sysadm_r」は非常に強い権限を持って

いますので，当然乱用するのは良くありません．

Webサイト管理者やメーリングリスト管理者など

を作成する場合には，専用のロールを作ることが

重要です．

FC2では，ユーザが選択可能なロール設定が甘

くなっていて，rootユーザは「sysadm_r」と

「staf f_r」が，一般ユーザは「sysadm_r」と

「user_r」が選択可能になっています．どちらも

「sysadm_r」の選択が可能となっているのは，使い

やすさのためです．

一般ユーザに「sysadm_r」ロールを選択可能に

することは，通常のLinuxでroot権限を与えること

と同じで，非常に危険と思われるかもしれません

が，実はそれほど危険ではありません．

本特集1章の図4を思い出してください．LSMは

rootでも回避できないセキュリティチェックを実現

していますが，パーミッションチェックをなくし

ているわけではなく，パーミッションチェックは

依然として有効です．したがって「sysadm_r」の

一般ユーザは，「sysadm_r」のrootユーザより弱い

権限しかありません．ただし，suコマンドで root

ユーザになると同じ権限を持つようになります．

では，実際にログインしてみましょう．

●ログイン

¡テキストログイン

テキストログインでは，ログイン時にロール選

択ができるようになっています（図3）．

Oct. 2004 - 35

2章◆これで完璧！ SELinuxのインストール／基本操作

デフォルトのロールについて

デフォルトで用意されているロール

選択可能なロール

基本操作

ログインとロール確認／変更

Localhost login: rootPassword:Your default context is root:sysadm_r:sysadm_tDo you want to choose a different one? y[2] root:staff_r:staff_t

Enter number of choice:

●図3 テキストログイン時のロール選択

何も入力せずに•を押すとnとして実行される

y ①

②

①rootでログインすると，デフォルトのロール以

外を選択したいかを聞いてきます．デフォルト

のロールで良い場合は，nもしくは•を押

せば，デフォルトのロールでログインします．

②yを押すとほかに選択できるロールが表示され

ます．なお，テキストログインでのデフォルト

のロールは，rootユーザが「sysadm_r」，一般ユ

ーザが「user_r」となっています．

¡グラフィカルログイン，sshログイン

グラフィカルログインやsshログインでは，ログ

イン時にロール選択ができません．デフォルトの

ロールはグラフィカルログインや sshログインで

は，rootユーザが「staff_r」，一般ユーザが「user_r」

となっています．

●ロールの確認

ログイン中の画面表示は，どのロールを選択し

ても同じなので，現在のロールを知ることはでき

ません．試しに，テキストログインにして，root

ユーザの「staff_r」を選択してログインしてみてく

ださい．

現在のロールを確認ために，「getcon」コマンド

が用意されています．「getcon」コマンドを実行す

ると，ユーザ名／ロール名／ユーザシェルのドメ

イン名が出力されます．rootユーザで「staff_r」を

選択してログインした後では，図4①のように表示

されます．

●ロールの変更

次に，ロールの変更をしてみましょう．ロール

変更には「newrole」コマンドが用意されています．

使い方は，「newrole -r [ロール名]」です．

たとえば，グラフィカルログイン，sshログイン

したときの状態で「newrole -r sysadm_r」を実行し

てみましょう．するとパスワードが要求されます

ので，ログインしたときのユーザ（ここでは root

ユーザ）のパスワードを入力してください（図4②）．

以上でロールの変更が終了します．

ロール変更がされていることを「getcon」コマ

ンドで確認してみましょう．図4③のように変更さ

れていることがわかります． r o o tユーザは

「sysadm_r」と「staff_r」が選択可能ですが，ふだ

んは「staff_r」を使い，管理時に「sysadm_r」を利

用すれば，操作ミスによる被害を抑えることがで

きます．

本特集1章のTEの説明で，「プロセスにはドメ

インを，ファイルなどのリソースにはタイプを付

ける」と説明しました．ここでは実際どんなドメ

インやタイプが付けられているかを確認してみま

しょう．

SELinuxでは，この確認のために「ps」や「ls」

コマンドが拡張されています．ドメインやタイプ

の確認には「-Z」オプションを付けます．

では「ps -eZ」を実行してみましょう（図5）．「-

Z」オプションを付けると，図5①の情報が出力さ

れます．これは，プロセスのセキュリティコンテ

キストと呼ばれるもので，「起動元のユーザ：起動

元のロール：ドメイン」で構成されています．シ

ステムが立ち上げたプロセスは，起動元のユーザ

が「system_u」，起動元のロールが「system_r」と

なります．プロセスのドメインは図5②に出力され

ています．

次に，「ls -Z」を実行してみましょう（図6）．「ps」


#getconroot:staff_r:staff_t# newrole -r sysadm_rAuthenticating root.Password:# getconroot:sysadm_r:sysadm_t

●図4 ロールの確認と変更

①

②

③

# ps -eZPID CONTEXT COMMAND1 system_u:system_r:init_t init [5]2 system_u:system_r:kernel_t [ksoftirqd/0]3 system_u:system_r:kernel_t [events/0]4 system_u:system_r:kernel_t [kblockd/0]…

●図5 プロセスのドメイン確認

①プロセスのセキュリティコンテキスト

②ドメイン

略

ドメインとタイプの確認

コマンドのときと同様に，図6①の情報が出力され

ます．これは，ファイルやディレクトリのセキュ

リティコンテキストです．SELinuxでは，ドメイン

もタイプも同じように扱うので，起動元のユーザ

と起動元のロールにダミーの値が入っています．

ファイルやディレクトリのタイプは図6②に出力さ

れています．

●モードの確認方法

現在動作している SELinux機能のモードが，

「permissiveモード」と「enforcingモード」のどち

らなのかという情報は「/selinux/enforce」ファイ

ルに記述されています．この内容が 0 なら

「permissiveモード」で1なら「enforcingモード」

です．

したがって，このファイルをmoreコマンドなど

見ることでモードを確認できますが，「getenforce」

コマンドでも確認できます．また，モード変更も

「/selinux/enforce」を書き換えるという方法もあり

ますが，「setenforce」コマンドが用意されていま

す．

●実際にモードを変更してみる

では，enforcingモードで起動し，rootユーザの

「staff_r」でログインして，実際のモード確認とモ

ード変更を行ってみましょう（図7）．

①「getenforce」コマンドで現在のモードが出力さ

れます．

②試しに「setenforce」コマンドで「permissiveモ

ード」に変更しようとしています．ロールを変

更していないのでエラーが返されます．モード

変更のためには，「/selinux/enforce」を書き換え

る権限が必要となります．この権限は，rootユ

ーザで，かつ「sysadm_r」ロールでなければな

りません．そのため，「sysadm_r」でも一般ユー

ザの場合は同じようにエラーとなります．

③「sysadm_r」になります．

④「setenforce」コマンドを実行します．今度はエ

ラーになりません．

⑤モードを確認してみると，「permissiveモード」

になっていることがわかります．

●OS起動時にモードを変更する方法

先ほどは起動中のモード変更を説明しましたが，

OS起動時にモードを変更して起動したい場合もあ

るでしょう．たとえば，「enforcingモード」でうま

く起動しないため「permissiveモード」で起動した

い場合などです．この場合はGRUBの起動画面で

ブートパラメータに「enforcing=0」と付け加える

ことで，permissiveモードで起動させることができ

ます．

●SELinuxの無効化

また，SELinux機能を無効化し，普通のLinuxと

Oct. 2004 - 37


#ls -Z /etc/…-rw-r--r-- root root system_u:object_r:adjtime_t adjtimedrwxr-xr-x root root system_u:object_r:etc_t aep-rw-r--r-- root root system_u:object_r:etc_t aep.conf-rw-r--r-- root root system_u:object_r:etc_t aeplog.confdrwxr-xr-x root root system_u:object_r:etc_t alchemist-rw-r--r-- root root system_u:object_r:etc_aliases_t aliases-rw-r----- root smmsp system_u:object_r:etc_aliases_t aliases.db…

●図6 ファイル／ディレクトリのタイプ確認

①ディレクトリやファイルのセキュリティコンテキスト

②タイプ略

略

# getenforceenforcing# setenforce 0setenforce: setenforce() failed# newrole -r sysadm_rAuthenticating root.Password:# setenforce 0# getenforcepermissive

●図7 モードの確認と変更

①

②

③

④

⑤

モードの確認と変更

緊急時の起動モード変更とSELinuxの無効化

して起動させることもできます．この場合は

G R U B の起動画面でブートパラメータに

「selinux=0」と付け加えることで，SELinuxを無効

化することができます．

●注意点

これら起動時のSELinux機能モード変更や無効

化は，一時的なものです．次回以降も同じように

起動させるためには，「SELinux機能の有効化」の

項で説明したように「/etc/sysconfig/selinux」を編

集する必要があります．

また，ブートパラメータでSELinuxを無効化し

た場合でも，「/etc/sysconfig/selinux」の設定で無

効化した場合と同様に，ファイルやディレクトリ

のタイプ付けが失われてしまいます．そのため，

後でSELinux機能を有効にする場合には，「fixfiles

relabel」コマンドを実行することを忘れないでく

ださい．

SELinuxのログについては，本特集1章「監査ロ

グ」の項でも触れましたが，もう少し詳しく見て

いきましょう． SELinuxのログは，ほかのシステ

ムログと同様に「/var/log/message」に保存され

ます．SELinuxのログを見るためには，このファイ

ルを直接見ても良いですし，「dmesg」コマンドを

利用しても良いでしょう．

●実際にログを見てみる

では，rootユーザの「staff_r」でログインし，

「less /var/log/message」でログを見てみましょう．

といっても「staff_r」では，直接ファイルを見るこ

とはできません．しかし，rootユーザの「staff_r」

でも，「dmesg」コマンドを使うことでログを見る

ことができます．

先ほどの「less /var/log/message」の実行に対し

て図8のようなログが含まれていることが確認でき

るでしょう．

①ログが記録された時刻（カーネル時刻）です．

②ログの意味です．図8の例では，拒否されたた

めのログであることを示しています．

③ログの対象となったアクセスベクタです．ここ

では，ログの対象が読み込みのアクセスベクタ

readであったことを示しています．

④アクセス元のプロセスやアクセス先のリソース

の情報です．プロセスIDやプロセスの元となっ

た実行ファイル名，アクセス先のリソース名な

どが含まれます．この例では，「/bin/bash」が

「log」に対してアクセスしようとしたことなどを

示しています．この部分は，表示される情報が

ログによって異なる場合があり，完全ではない

ですが，プロセスやリソースを特定するために

役に立ちます．

⑤アクセス元のプロセスのドメインを含むセキュ

リティコンテキストです．この例では「staff_t」

ドメインであることを示しています．「staff_r」

でログインしたので，「/bin/bash」が「staff_t」

ドメインで動いていたことがわかります．

⑥アクセス先のリソースタイプを含むセキュリテ

ィコンテキストとクラスです．「var_log_t」タイ

プでdirクラスにアクセスしようとしたことを示

しています．

●タイプ付けの特徴と問題

新規作成されたファイルは，ディレクトリと同

じタイプが付けられます．この特徴がファイルを


audit(1089957396.658:0): avc: denied { read } for pid=2299 exe=/bin/bash name=log dev=hda2 ino=9617430 scontext=root:staff_r:staff_t tcontext=system_u:object_r:var_log_t tclass=dir

●図8 ログの例

1089957396.658

①時刻

readpid=2299 exe=/bin/bash name=log dev=hda2 ino=9617430scontext=root:staff_r:staff_ttcontext=system_u:object_r:var_log_t tclass=dir

③アクセスベクタ

④プロセスやリソースの情報⑤ドメイン⑥タイプとクラス

denied

②denied（拒否）or granted（許可）

SELinuxのログの見方

ファイルの新規作成／変更とタイプ付け

新規作成する際に問題になることはほとんどあり

ません．

しかし，ファイルを変更する際に，この特徴が

問題になります．Emacsなどの通常のエディタで

ファイルを変更すると，ファイルの消去と新規作

成と見なされ，ファイルのタイプがディレクトリ

と同じものになります．

たとえば，「/etc/named.conf」の変更を行ってい

る図9で見てみましょう．

①変更前のタイプが「named_conf_t」であること

がわかります．

②emacsコマンドで適当な変更を行い，保存して

みましょう．

③先ほどと同じように見てみると，タイプがetc_t

となっていることが分かります．

◆◆◆

このようにタイプが変更されてしまうと，TEで

の設定が正しく動作しなくなります．

●タイプ付け問題の解決方法

変更したファイルのタイプを戻すにはいくつか

方法があります．

1つは，「fixfiles relabel」コマンドを行う方法で

す．これにより，すべてのファイルが正しいタイ

プ付けに戻ります．ただし，この処理には非常に

時間がかかります．

もう1つの方法は，一部のファイルにラベル付け

を行う「setfiles」コマンドを利用する方法です．

コマンドの詳細は省略しますが，このコマンドも

多くのファイルのラベル付けを行うコマンドであ

り，1つのファイルを変更したときに利用するには

適切ではありません．

最後の方法は，タイプ付け変更コマンドである

「chcon」コマンドを使う方法です．先ほどの図9

をご覧ください．

④「chcon」コマンドでファイルのタイプを元に戻

しています．

⑤タイプが元に戻っていることがわかります．

◆◆◆

1つのファイルのタイプ付けを変更する場合には

「chcon」コマンドが有効でしょう．

このように，ファイルのタイプ付けを正しくす

ることはできますが，ファイル変更時にいちいち

ファイルのタイプ付けを気にするのは非常に大変

です．

そこで，FC2のviコマンドはタイプ付けが保存

されるように拡張されています．ファイル変更に

はviコマンドを利用するほうが効率的でしょう．

以上が，SELinux機能の有効化と基本的な操作

です．セキュリティポリシ設定の変更を行わない

で使う場合には，これだけ知っていれば十分でし

ょう．

セキュリティポリシ設定の変更では，

「permissiveモード」と「sysadm_r」を使うことに

なるので，本稿で紹介したモードやロールの変更

方法は覚えておきましょう．

また，「タイプ付け問題の解決方法」の項で述べ

たように，ファイルの変更にはviコマンドを使う

ほうが良いです．viコマンドに慣れていない人も，

これを機に使ってみてはいかがでしょうか．s

Oct. 2004 - 39


最後に

# ls -Z named.conf-rw-r--r--+ root root system_u:object_r:named_conf_t named.conf# emacs named.conf# ls -Z named.conf-rw-r--r--+ root root root:object_r:etc_t named.conf# chcon system_u:object_r:named_conf_t named.conf# ls -Z named.conf-rw-r--r--+ root root system_u:object_r:named_conf_t named.conf

●図9 ファイル変更時のタイプ

①

②

③

④

⑤

SELinux上のプロセスは，デフォルトでは何も

権限を持っておらず，必要な権限を1つ1つ許可す

ることで設定します．システムを正常に動作させ

るために必要な設定項目は，数万～数十万にもお

よび，このような膨大な設定をゼロから行ってい

ては，とてもSELinuxは使えません．

ポリシのサンプルを入手し，そのサンプルをカ

スタマイズして使用するのが一般的です．幸いに

して，Fedora Core 2にはポリシファイルも一緒に

添付されているので，大きな設定変更の必要なく

使用できます．

ポリシファイルの本体は，「/etc/security/selinux」

ディレクトリに格納されている「policy.17」と

「file_contexts」の2つです．policy.17ファイルは，

TE／RBAC／ドメイン遷移の設定が記述されてい

ます．このファイルはバイナリ形式であるため，

直接編集することはできません．

ファイルにどんなタイプを付与するかの設定は，

policy.17とは独立して，file_contextsファイルに記

述されています．このファイルはテキスト形式で

すが，編集内容が保持されないため，通常は編集

しません．

設定を編集するためには，ポリシのソースファ

イルと呼ばれるファイルが必要になります．ソー

スファイルを編集した後，ソースファイルを後ほ

ど紹介する方法でpolicy.17, file_contextsに変換し，

設定を反映します．今後「ポリシ」と言った場合

はとくに断りがない限り，こちらのソースファイ

ルを指すことにします．

ポリシのソースファイルはデフォルトではイン

ストールされていないため，以下の2つのパッケー

ジをインストールします．

¡policy-sources

ポリシのソースファイル

¡checkpolicy

ソースファイルをバイナリ形式のポリシ

（policy.17）に変換するコマンド


SELinuxの動作は，ポリシファイルに書かれている設定に依存しています．SELinuxを使ってセキュアなシステムを構築できるか否かは，ポリシファイルの設定記述にかかっています．本章では，SELinuxのポリシファイルと，実用上必要なポリシ記述の基礎知識を解説します．

日本SELinuxユーザ会準備委員会中村雄一 NAKAMURA Yuichi ●[email protected]


ポリシファイルについて

ポリシファイルの用意

ポリシファイルの本体

ポリシのソースファイル

ポリシのソースファイルをインストールする

これらは，Fedora Core 2のインストールメディ

アに入っていますので，図1のようにインストール

します．

ポリシのソースをインストールすると，

「/etc/security/selinux/src/policy」というディレク

トリが新たに生成されています．このディレクト

リ下には複数のディレクトリ／ファイルがあり，

ここに設定が記述されています．

これらのうち，設定を行ううえで最も重要なも

のは「domainsディレクトリ」と「file_contextsデ

ィレクトリ」です．

●domainsディレクトリとteファイル

このディレクトリの中のファイルで，TE／ドメ

イン遷移の設定が行われています．「te」という拡

張子のファイルが設定ファイルで，表1のように分

割して格納されています．これらのファイルは，

通称「teファイル」と呼ばれます．

とくに重要なのがprogramディレクトリの中の

「アプリケーション名.te」というファイルです．た

とえば，apache.teというファイルではApacheに関

連する設定が行われています．

●file_contextsディレクトリとfcファイル

このディレクトリの下にあるファイルで，ファ

イルにどのようなタイプを与えるかの設定が行わ

れています．「fc」という拡張子のファイルに，表

2のように格納されています．types.fcファイルと，

program以下の「アプリケーション名.fc」ファイル

が重要で，よく編集します．これらのファイルは

通称「fcファイル」と呼ばれます．

◆◆◆

なお，file_contexts/program以下

の fcファイルは，domains/program

以下に存在する teファイルと対にな

っています．たとえば，

hoge.fcというファイル

を file_contexts/program

に作成した場合，同時に

h o g e . t e ファイルを

domains/programに作成

しないと，設定反映時に

エラーになります．

ポリシを編集しただけ

では，設定は反映されま

せん．設定を反映する操

作を行う必要がありま

す．設定の反映は

¡ポリシをカーネルに読

み込ませる

¡ファイルのタイプ付け

を反映する

Oct. 2004 - 41

3章◆SELinux設定方法の基礎～ポリシファイル編集法

ファイル／ディレクトリ意味

user.teuser_r，staff_r ロールのシェルに対するドメイン user_t，

staff_tに関する設定が行われています

admin.tesysadm_r ロールのシェルに対するドメイン sysadm_t の

設定が行われています

miscカーネル用のドメインkernel_t の設定が行われていますが，

このディレクトリの存在意義は薄れてきています

programこのディレクトリ下の「アプリケーション名.te」という

ファイルで，アプリケーションに関連する設定が行われています

●表1 domainsディレクトリの構造

ファイル／ディレクトリ意味

すべてのfcファイルを1つにまとめたものです．設定反映時に

file_contexts 動的に生成されるため，このファイルを編集しても編集内容は

反映されません

misc 使われていません

types.fc システムファイルに関連のタイプ付けが記述されています

program「アプリケーション名.fc」というファイルに，アプリケーション

に関連したファイルのタイプ付けが記述されています

●表2 file_contextsディレクトリの構造

#rpm -ivh policy-sources-1.11.3-3.noarch.rpm checkpolicy-1.10-1.i386.rpm

#yum install policy-sources checkpolicy

●図1 ポリシのソースファイルをインストール

または

ポリシの構造

設定の反映

という2段階になっています．設定を反映する場合

は，rootユーザかつsysadm_rロールでログインし

ます．

作業ディレクトリは，必ずポリシのディレクト

リ（/etc/security/selinux/src/policy）とします．

# cd /etc/security/selinux/src/policy

以下，断りがない限り，カレントディレクトリは

このディレクトリであるとします．

●ポリシをカーネルに読み込ませる

# make reload

と実行することによって，teファイルの内容を1つ

にまとめ，バイナリ形式のポリシpolicy.17に変換

し，ポリシをカーネルに読み込ませます．teファ

イルのみ編集した場合は，これだけで設定を反映

できます．

●ファイルのタイプ付けを反映する

fcファイルを編集し，ファイルのタイプ付けを

変更した場合は，make reloadだけでは設定は反映

されません．make reloadを行った後，

# make relabel

または

# fixfiles relabel

を実行し，全ファイルのタイプを fcファイルに設

定されているとおりに付与しなおします．

ただし，fcファイルを編集するたびに全ファイ

ルのタイプを付与しなおすのは時間がかかります．

そこで，次のようにsetfilesコマンドを使えば，タ

イプ付けを変えたディレクトリに対してのみ，設

定反映を行うことができます注1．

# setfiles file_contexts/file_contexts

（タイプを変更したディレクトリ）（実際は1行）

domainsディレクトリ，file_contextsディレクト

リの下には，多くのアプリケーションに関するポ

リシが用意されていますが，すべてのアプリケー

ションに対するポリシが用意されているわけでは

なく，ポリシの整備状況がアプリケーションによ

ってばらつきがあります．ポリシの整備状況によ

って，必要な設定が異なってきます．表3にポリシ

の整備状況を示します．

表3aのアプリケーションについては，とくに

何も設定せずに動作します．つまり，プロセスに

はドメイン遷移により適切なドメインが割り当て

られ，ドメインの権限設定も揃っています．たと

えば，Apache（/usr/sbin/httpd）は，「httpd_t」ド

メインを付与され，必要なファイルにきちんとア


注1）setfilesを使う場合は，あらかじめmake reloadをする必要があります．

make relabelやfixfilesコマンドを使うと，/tmpを消去

してしまいます．とくにXを使っている場合はXが動作し

なくなりますので注意が必要です．

さらに，これらのコマンドを使った後は，一度ログアウ

トして再度ログインする必要があります※．なお，setfiles

コマンドの場合は，これらの問題は起こりません．

make relabelとfixfilesの注意点



※端末ファイルのタイプが書き換えられるため，コマンドがコンソールにアクセスできなくなり，アクセス拒否ログが出力されます．

そこで，ログアウトすることで端末ファイルのタイプをリセットしています．

設定が必要な場合

そのまま使用できるアプリケーション

クセスできるような設定が施されています．

しかし，表3b～dのアプリケーションを動作

させようとすると，設定が必要になります．設定

が必要になる理由は，大きく以下の2つに分けられ

ます．

q適切なドメインが割り当てられるが，

アプリケーションが動作しない

表3bのアプリケーションを動作させようとし

た場合に相当します．アプリケーションに適切な

ドメイン注2が割り当てられても，必要なリソース

へのアクセス権限がなければ，アプリケーション

は正常に動作しません．

たとえば，vsftpdは ftpd_tドメインで動作していま

す．しかし，ftpd_tドメインは，FTP公開ディレクト

リへのアクセス権限を持っていないため，当然

vsftpdは動作しません．このような場合は，拒否さ

れたアクセスを許可する設定をする必要があります．

wアプリケーションに適切なドメインが

割り当てられない

表3c～dのアプリケーションを動作させよう

とした場合に相当します．設定が揃っていないと，

アプリケーション起動時にドメイン遷移が起きず，

アプリケーションに対応したドメインが付与され

ません．その場合は，起動スクリプトのドメイン

「 in i t rc_t」または，ユーザシェルのドメイン

（sysadm_t，user_t，staff_t）をそのまま引き継いで

アプリケーションが動作します．

アプリケーションによっては，これらのドメイ

ンで正常に動作する場合もあります．しかし，こ

れらのドメインは，大きな権限を持っています．

とくに，initrc_t，sysadm_tはシステムに致命的な

被害を及ぼしうる権限を持っています．このよう

な大きな権限でアプリケーションを動作させてし

まっては，「プロセスは最小限の権限で動作するた

め，侵入されても被害は最小限」というSELinux

の恩恵を受けられなくなってしまいます注3．

本特集では，qの場合に，SELinux上でアプリケ

ーションを正常に動作させるための設定方法を紹

介します．今回紹介する設定方法だけで，Webサ

ーバ／FTPサーバ／ネームサーバ／メールサーバ

のような主要なサーバアプリケーションをセキュ

アに動作させることができます．

Oct. 2004 - 43


アプリケーション設定ファイル

Apache apache.te，apache.fc

sendmail sendmail.te，sendmail.fc

BIND named.te，named.fc

OpenSSH ssh.te，ssh.fc

Samba samba.te，samba.fc

canna canna.te，canna.fc

●表3a ポリシが整備されているアプリケーション


CGI，PHP apache.te，apache.fc

vsftpd ftpd.te，ftpd.fc

Postfix postfix.te，postfix.fc

●表3b 簡単な設定追加が必要なアプリケーション


PostgreSQL postgresql.te，postgresql.fc

MySQL mysqld.te，mysqld.fc

●表3c 大きな設定変更が必要なアプリケーションアプリケーション

FreeWnn

IIIMF

Tomcat

●表3d ポリシが用意されていないおもなアプリケーション

注2）ここで言う「適切なドメイン」とは，アプリケーションに関連した名前のドメインが割り当てられている場合のことを言います．

注3）これらのドメインで動作している場合でも，ローカルコマンドなら問題ありません．

そのままでは動作しないアプリケーション

今回紹介する設定方法

●wの対処法

ただし，wについては，今回の方法でとりあえ

ずは動作させることができますが，大きな権限で

動作することになるため安全ではありません．安

全性が低くなることを承知して動作させるか，ア

プリケーションを使わないことを検討する必要が

あります．

本来は，適切なドメインが割り当てられるよう

に設定を記述する必要があります．しかし，この

作業は高度な知識を必要とするため，本特集では

紹介しません．コミュニティからポリシが公開さ

れるのを待つのが得策です．たとえば，

Pos t g r eSQLを動作させるためのポリシは，

SELinuxユーザーズメーリングリストに公開され

ています注4．また，Tomcatについても，完全では

ないものの，動作方法が公開されています注5．

では，アプリケーションがうまく動作しない場

合の設定方法を見てみましょう．設定の追加の手

順は図2のようになります．

①アプリケーションが動作しない原因がSELinux

の設定にあるかどうかを切り分けます

②アプリケーションが動作しない原因がSELinux

であった場合，ログをチェックし，どんな権限

が足りないのかを調べます．実際の設定作業に

ついては，安全性と簡単さのどちらを重視する

かで2通りの方法があります

③アクセス拒否ログを元に「自動的に」設定を追

加します．簡単ですが安全性は落ちます

④アクセス拒否ログを元に「手動で」設定を追加

します．より安全性を高める場合はこちらを選

びます

ここでは，vsftpdの設定を例として，この流れに

沿って設定をします．SELinux上での，vsftpdはFTP

公開ディレクトリにファイルを公開できません．

まず，FTP公開ディレクトリにファイルを公開

できないことを確認します．ダミーの公開ファイ

ルhoge.txtを作成します．

# echo "hoge" > /var/ftp/pub/hoge.txt

vsftpdを起動します．

# /etc/rc.d/init.d/vsftpd start

FTPサーバにアクセスし，ユーザ名Anonymous，

パスワードなしでログインします．すると，ログイ

ンは成功しますが，公開ディレクトリにあるはずの

ファイル「hoge.txt」を見つけることができません．

ポリシのディレクトリに移動します．

# cd /etc/security/selinux/src/policy

以下，このディレクトリがカレントディレクト

リであるとして話を進めていきます．

まずは，SELinuxの設定の問題であるか否か，問

題の切り分けを行います．切り分けポイントは以

下の2ヵ所です．

●アプリケーション自体の問題なのか確認

まずは，SELinuxが無効の状態でアプリケーショ

ンが正しく動作することを確認します．permissive


注4）http://www.selinux.hitachi-sk.co.jp/selinux-users-ml/200407.month/399.html

注5）http://www.selinux.gr.jp/documents/FC2-SELinuxmemo.html

①問題切り分け

②動作テストおよびログのチェック

③簡易設定 ④安全な設定

●図2 設定の追加手順

一般的な設定追加方法

vsftpdを設定してみる

問題切り分け

モードにして，アプリケーションの動作テストを

行い，正しく動作することを確認します．

permissiveモードならば，SELinuxのアクセス制御

機能は無効になっています．

# setenforce 0

再びFTPサーバにアクセスし，ユーザ名Anony

mous，パスワードなしでアクセスすると，今度は

hoge.txtをダウンロードすることができます．これ

で，vsftpd自体には問題なく，問題はSELinuxの設

定にあることがわかりました．

permissiveモードは安全ではないですので，動作

確認の後は，

#setenforce 1

にて，enforcingモードに戻しておきます．

●ファイルのタイプをチェック

今まで動作していたアプリケーションが突然動

作しなくなった場合，設定をいじる前にまずはフ

ァイルのタイプが適切に付与されているかどうか

を疑う必要があります．なぜなら，本特集2章で紹

介したように，ファイルの上書きなどでファイル

タイプの情報が変化することがあり，突然アプリ

ケーションが動作しなくなることがあるからです．

このような場合は，

#fixfiles relabel

を実行し，すべてのファイルのタイプを正しく付

与しなおし，再度動作確認します．

今回のvsftpdの場合は，fixfiles relabelをしても公

開ファイルにアクセスできませんので，ファイル

のタイプ問題には関係ないことがわかります．

以上の問題切り分けを行っても，アプリケーシ

ョンが動作しない場合，正常に動作するための権

限が足りない可能性が高いです．アプリケーショ

ンを動作させるための設定をポリシファイルに記

述する必要があります．

どんな権限が足りないのかを調査するためには，

permissiveモードでアプリケーションをテスト動作さ

せます．テストの間出力されたログを見ることによ

って，どんな権限が足りないのかをチェックします．

今回のvsftpdの場合は，「アプリケーション自体

の問題であるかどうか確認」のところで，

permissiveモードで動作テストをしていますので，

このときに出力されたログをチェックします．

さきほどの動作テストで出力されたログをリス

ト1に示します．/var/ftp以下の読み込みアクセス

が拒否されていることがわかります注6．以降，こ

のログを元にしてこのアクセスを許可する設定を

追加していきます．

アクセス拒否ログを元に設定を追加する方法は2


audit(1088910368.044:261902): avc: denied { read } for pid=1708 exe=/usr/sbin/vsftpd name=ftp dev=sda2 ino=113950 scontext=root:system_r:ftpd_t tcontext=system_u:object_r:var_t tclass=dir

audit(1088910370.215:262129): avc: denied { getattr } for pid=1708 exe=/usr/sbin/vsftpd path=/pub/hoge.txt dev=sda2 ino=114054 scontext=root:system_r:ftpd_ttcontext=root:object_r:var_t tclass=file

audit(1088910374.139:262326): avc: denied { read } for pid=1708 exe=/usr/sbin/vsftpd name=hoge.txt dev=sda2 ino=114054 scontext=root:system_r:ftpd_t tcontext=root:object_r:var_t tclass=file

●リスト1 動作テストで出力されたログ

↑意味：vsftpd（ftpd_tドメイン）のftpディレクトリ（var_t）に対するreadアクセスが拒否された

↑意味：vsftpd（ftpd_tドメイン）の/var/ftp/pub/hoge.txtファイル（var_t）に対するgetattrアクセスが拒否された

↑意味：vsftpd（ftpd_tドメイン）の/var/ftp/pub/hoge.txtファイル（var_t）に対するreadアクセスが拒否された

動作テストおよびログのチェック

簡易設定：ログから設定に単純に変換

注6）リスト1のログを見るとわかるように，アクセス拒否されたファイルのフルパスがつねに表示されるとは限りません．「path=」の後に

はフルパスが表示されますが，「name=」の後にはファイル名のみが表示されます．フルパスを知るにはlocateコマンドを使ったり，

「rpm -ql vsftpd」として，vsftpdに関連するファイルを表示する方法があります．

※/var/ftp/pubディレクトリへのアクセス拒否ログの出力は抑制されています．詳細はコラム「ログについてのよくあるトラブル」を参照してください．

Oct. 2004 - 45

つあります．この項では，簡単に設定を追加する

方法を解説します．

●allow文

アクセスを許可するためには，「allow文」とい

う設定要素を teファイルに記述します．allow文の

書式は次のようになります．

allowドメインタイプ:オブジェクトクラス {アク

セスベクタ }; （実際は1行）

たとえば，

allow httpd_t httpd_sys_content_t:file

{ getattr read }; （実際は1行）

と記述すると，httpd_tドメインは，httpd_sys_

content_tタイプのファイル（オブジェクトクラス

file）にgetattr（ファイルの属性を得る）／ read

（読み込み）アクセスができるようになります．

●アクセス拒否ログをallow文に変換する

アクセス拒否ログには，ドメイン／タイプ／オ

ブジェクトクラス／アクセスベクタの情報が載っ

ているので，それをそのままallow文とすれば，拒

否されたアクセスを許可する設定を記述すること

ができます（リスト2，3）．

●audit2allowコマンドで設定を自動化する

allow文をいちいち手作業で記述していくのは面

倒なので，アクセス拒否のログをallow文に自動的

に変換するコマンド「audit2allow」を使うと便利で

す．audit2allowはFedora Core 2に標準で添付され

ています．audit2allowの書式を図3，オプションを

表4に示します．

では，audit2allowコマンドを使ってみましょう

（図4）．

dmesgコマンドで出力されるアクセス拒否ログ

をallow文に変換しています．ここで出力された設


設定作業を行う場合，アクセス拒否のログを使って設

定していきますが，アクセス拒否のログはつねに出力され

るわけではないので注意が必要です．次のような原因でロ

グが出力されない場合があります．

①permissiveモードでのログ出力の抑制

permissiveモードでは，一度出力されたログと同じロ

グはしばらくの間出力されません．動作テストを何度も行

うとログが出力されず，困ることがよくあります．その場

合は，enforcingモードに一度戻し，再度permissiveモー

ドに切り替えれば，ログが出力されるようになります．

②ログが出力されないようになっている場合

ホームディレクトリへのアクセスなど特定のアクセス拒

否のログは出力されないようになっています．図Aで，す

べてのアクセス拒否ログが出力されるようになりますが，

余計なログも出力されるようになります．元に戻すには，

図Bとします．

③ログの取りこぼし

拒否されたアクセスが多すぎる場合，ログ出力が追い

つかず，ログが捨てられてしまうことがあります．そのた

め，ログに対応した設定を追加し再度テストしても，な

おもアクセス拒否のログが出てうまく動作しないことがあ

ります．このような場合は，正常に動作するまで動作テ

ストと設定追加を繰り返していくしかありません．

ログについてのよくあるトラブル



# cd /etc/security/selinux/src/policy# make enableaudit# make reload

●図A すべてのアクセス拒否ログを出力

# make clean # make reload

●図B 元の出力に戻す

定のうち，リスト1のログ（vsftpdがアクセス拒否

されたログ）に関連した設定は，図の白枠の部分

です．

設定反映後，再度audit2allowをそのまま使うと，

すでに追加した設定まで出力されてしまいます．

ここでは，余計な設定の出力を抑制するために「-l」

オプションを付与しています．すると，設定を反

映した後に新たに出力されたログのみが読み込ま

れますので，余計な設定が出力されません．「-l」

オプションによる弊害はありませんので，つねに

「-l」オプションを付けておくことをお勧めします．

●設定を追加／反映する

では，vsftpdを正しく動作させるためにallow文

を追加しましょう．設定を追加する場所ですが，

domainsディレクトリ以下の teファイルのどこに追

加してもかまいませんが，アプリケーションに関

連した設定ファイルに追加したほうがわかりやす

いです．

先ほどaudit2allowで出力された図4の白枠

部分をdomians/program/ftpd.teに追加しま

す．その後，設定を反映します．

# make reload

make reloadに時間がかかる場合は，コラム

「make reloadの時間短縮」を参考にしてくだ

さい．今回は，fcファイルを編集していない

ため，make relabelまたはsetfilesの必要はあ

りません．

では，enforcingモードにて，FTPの公開ファイ

ルにアクセスしてみましょう．今度はきちんとア

クセスできるはずです．

●ログを元にした単純設定の問題

これまで，audit2allowを使ってログをallow文に

変換して設定を行う方法を紹介しました．しかし，

この方法は手軽な反面，余計な権限を与えること

があります．

たとえば，先ほどの設定で追加された設定を見

てみると，「ftpd_tドメインは，var_tタイプのディ

レクトリ／ファイルに読み込みアクセスできる」

という設定が出力されています．このvar_tタイプ

は，/var以下の多くのディレクトリのタイプです

ので，ftpd_tドメインは/var以下の多くのファイル

に対してアクセスできるようになっています．

しかし，リスト1のログを見てみると，ftpd_tド

Oct. 2004 - 47


オプション意味

-d dmesgのログを入力とする

-v allow文と一緒に詳しい情報を出力する

-l 最後に設定を反映した後のログだけを読み込む

-i ファイルから入力する

-o ファイルに設定を追記する

●表4 audit2allowのオプション

# audit2allow -d -lallow ftpd_t var_t:dir { read };allow ftpd_t var_t:file { getattr read };allow lvm_t dri_device_t:dir { read };allow lvm_t file_t:dir { getattr };

●図4 audit2allowの使用例

allow ftpd_t var_t:dir { read };allow ftpd_t var_t:file { getattr read };

allow ftpd_t var_t: dir { read };

●リスト3 対応するallow文

readftpd_t var_t dir

アクセスベクタドメインタイプオブジェクトクラス

audit2allow [-d] [-v] [-l] [-i 入力ファイル] [-o 追記するファイル]

●図3 audit2allowの書式

audit(1088910368.044:261902): avc: denied { read } for pid=1708 exe=/usr/sbin/vsftpd name=ftp dev=sda2 ino=113950 scontext=root:system_r:ftpd_t tcontext=system_u:object_r:var_t tclass=dir

●リスト2 アクセス拒否のログ

readftpd_t

var_t dir

アクセスベクタ

ドメインタイプオブジェクトクラス

安全な設定法：タイプを付与して直接アクセス権限を記述

メインは，実際には/var/ftp以下のディレクトリ／

ファイルにだけアクセスできれば良いことがわか

ります．

●最小限の権限を与える方法

最小限の権限を与えるためには，プロセスがア

クセスしているファイルに対して独自のタイプを

割り当てます．リスト1のログを見ると，vsftpdは，

/ v a r / f t p 以下のディレクトリ／ファイル

（/var/ftp/pub，/var/ftp/pub/hoge.txt）にアクセス

することがわかっています．つまり，/var/ftp以下

に，「pub_t」というタイプを付与し，「ftpd_tは

pub_tに読み込みアクセスできる」と設定すれば，

ftpd_tドメインは，/var/ftp以下だけに対するアク

セス権限だけを持ちます．

ただし，すべての場合にタイプを分けるのは煩

雑です．一般的には，etc_t／var_t／var_lib_tのよ

うな多くのファイルに付与されているタイプへの

アクセスがある場合にタイプを分けるのが良いで

しょう．とくに，書き込みアクセスがある場合は

タイプを分けることをお勧めします．

実際の設定の手順は，①タイプの宣言，②タイ

プの付与，③タイプに対するアクセス許可の記述，

④設定の反映／テストのようになります．設定を

する前に，簡易設定で追加した設定（図4の白枠部

分）を，domains/program/ftpd.teから削除します．

①タイプの宣言

タイプを使うためには，タイプを使うことを宣

言する必要があります．タイプの宣言のためには，

次のような「type文」を teファイルに記述します．

typeタイプ,file_type,sysadmfile;

今回は，domains/program/ftpd.teに，

type pub_t,file_type,sysadmfile;

と記述します．このタイプの宣言を忘れると，設

定反映時にエラーになりますので注意してくださ

い．

②タイプの付与

タイプを付与するためには，fcファイルにファ

イルとタイプの関連付けを記述します．書式は次

のとおりです．

ファイル名（正規表現可） system_u:object_r:

タイプ（実際は1行）

ファイル名の指定で正規表現を使うことで，ま

とめてタイプを付与することが可能ですが，実用

上は「ディレクトリ(/.*)?」のように，「ディレク


make reloadを行うと，policyディレクトリ以下のポリシ

が，バイナリ形式のポリシ「policy.17」に変換されます．

この変換作業の中で「policy.15」「policy.16」という2つ

のファイルも生成されます．これらのファイルは，カーネ

ル2.4ベースのSELinuxが使うファイル

ですが，Fedora Core 2はカーネル2.6

ですので，これら2つのファイルは必要

ありません．

/etc/security/selinux/src/policy/Makefile内にあるリスト

Aの2行の先頭に「#」を付けてコメントアウトすれば，

policy.15，policy.16は生成されなくなり，make reload

の時間が短縮できます．

make reloadの時間短縮



$(CHECKPOLICY) -c 15 -o $(INSTALLDIR)/policy.15 policy.conf$(CHECKPOLICY) -c 16 -o $(INSTALLDIR)/policy.16 policy.conf

●リストA policy.15，policy.16を生成しないようにする

実際の設定

トリ以下のすべてのファイルを指定」という正規

表現を覚えておけば十分でしょう．

vsftpdに関連した fcファイルは file_contexts/

program/ftpd.fcですので，このファイルに

/var/ftp(/.*)? system_u:object_r:pub_t

と記述します．これは，/var/ftp以下のディレクト

リ／ファイルにpub_tタイプを付与する設定です．

③タイプに対するアクセス許可の記述

ファイル／ディレクトリにタイプを付与する設

定を記述したところで，今度は，ドメインがタイ

プにアクセスできるようにする設定を記述します．

allow文で設定を記述しても良いのですが，マクロ

と呼ばれる設定を使うと便利です．

マクロとは，複数の設定をまとめて行うための

しくみです．

例として，「r_dir_file」というマクロを見てみまし

ょう．これは，ドメインにファイル／ディレクト

リを読み込む権限を与えるために使います．

r_dir_file(hoge_t,foo_t)

と記述すると，リスト4（hoge_tが foo_tのディレ

クトリ／ファイル／シンボリックリンクを読み込

むことができるという意味）のような設定をした

のと同じになります．このほかにも，表5のような

マクロをよく使います．

どんなマクロを使うべきかは，アクセス拒否ロ

グを見て，どんなアクセスベクタが拒否されてい

るのかを目安にします．どんなマクロを使うのか

の目安も併せて表5に示します．

今回の例では，リスト 1のログを見てみると，

/var/ftp以下の read，getattrが拒否されています．

そこで，表5を見ると「r_dir_file」マクロを使えば

良いことがわかります．

したがって，domains/program/ftpd.teに，

r_dir_file(ftpd_t,pub_t)

と記述し，ftpd_tがpub_tタイプのファイル／ディ

レクトリを読み込めるようにします．

④設定の反映／テスト

では，設定を反映しましょう（図5）．

①今回は，ファイルに新たなタイプを付与している

ので，make reloadだけでなくsetfilesも必要です

②/var/ftpにpub_tタイプが付与されていることを確

認します

③enforcingモードであることを確かめます

vsftpdが本当に動作するか，もう一度テストして

みましょう．もしも足りない権限があれば，適宜

追加します．

Oct. 2004 - 49


allow hoge_t foo_t:dir { read getattr lock search ioctl };allow hoge_t foo_t:{ file lnk_file } { read getattr lock ioctl };

●リスト4 r_dir_file展開後の例

マクロ与える権限目安となるログ中のアクセスベクタ

r_dir_file ディレクトリ／ファイルの読み込み getattr，read

ra_dir_file ディレクトリ／ファイルの追記 append

rw_dir_file ディレクトリ／ファイルの読み書き write

rw_dir_create_fileディレクトリ／ファイルの読み書きに加え，（オブジェクトクラスfileの）

ファイルの生成／消去 create，unlink

create_dir_fileディレクトリ／ファイルの読み書きに加え，（オブジェクトクラスdirの）

ディレクトリ／ファイルの生成／消去 create，unlink

●表5 ファイルのアクセス権限を設定するときに利用するマクロ

Fedora Core 2に添付されているポリシでは，

「tunable.te」というファイルが用意されており，設定

を大まかに調整できるできるようになっています．

用途に応じて，設定を切り替える際に便利です．

たとえば，dmesgコマンドを利用する例を見て

みましょう．一般ユーザにこのコマンドの利用許

可を与えると，ユーザがシステムの状態を知るこ

とができ，障害発生時に迅速な報告が期待できま

す．一方，ユーザにシステムの情報を知られたく

ない場合は，dmesgコマンドを使わせないほうが

良いでしょう．このような場合に，tunable.teを

使えば「用途によってdmesgを使わせる／使わ

せない」といった設定の切り替えが簡単にできま

す．

tunable.teには，

define(̀ allow_user_dmesg')

のような「define(`定義要素')」という行が並んで

います．この行の意味は，「allow_user_dmesgを定

義する」という意味です．

ポリシファイルの中では，「allow_user_dmesgが

定義されていれば，一般ユーザ用ドメイン（staff_t，

user_t）はdmesgコマンドを使える」といった条件

分岐が記述されています．そして，tunable.teで，

allow_user_dmesgが定義されていますので，一般

ユーザ用ドメインでdmesgコマンドを使えます．

逆に，allow_user_dmesgを定義しないようにす

れば，一般ユーザ用ドメインはdmesgを使えなく

なります．この行を

# define(̀ allow_user_dmesg')

または

dnl define(̀ allow_user_dmesg')

のように，行頭に「#」か「dnl」を付与すれば，

定義しないようにできます．

編集した後，「# make reload」で設定を反映すれ

ば，staff_rでログインして，dmesgコマンドを使お

うとしても，使うことができません．

そのほかに tunable.teで定義されているおもな要

素を表6に示します．これらの要素のうちいくつか

は，次章で実際に使ってみます．

次章では，本章で解説した設定の基礎知識を踏

まえたうえで，安全なWebサーバ構築方法を解説

します．s


定義内容意味

unrestricted_admin sysadm_tドメインがほぼ何でもできる

ssh_sysadm_login SSHで直接sysadm_rロールでログインできる

allow_user_dmesg sysadm_rロール以外で，dmesgコマンドを使うことができる

user_canbe_sysadm 一般ユーザでもsysadm_rロールになれる

user_can_mount sysadm_rロール以外でmountコマンドを使うことができる

表6 tunable.teで定義されている要素

# cd /etc/security/selinux/src/policy# make reload# setfiles file_contexts/file_contexts /var

# ls -Z /vardrwxr-xr-x root root system_u:object_r:pub_t ftp

# getenforceenforcing

図5 設定の反映／テスト

①設定を反映

②タイプを確認

③モードを確認

用途に応じた設定の調整：tunable.te

tunable.teの使い方

終わりに

Oct. 2004 - 51

本特集3章で紹介したように，tunable.teを使う

ことにより，用途に応じた設定の調整が可能です．

Fedora Core 2では，SELinuxをより多くの人に使

ってもらうため，クライアントマシンとして使い

やすいように調整されており，ログインユーザに

対する設定が甘くなっています．ですので，この

ままサーバマシンとして使用するのは大変危険を

伴います．

ここでは，Webサーバ用として使うために，よ

り安全性に重点を置いた設定のチューニング方法

を紹介します．

tunable.teのうち，サーバとして使うには望まし

くない定義は，以下の2つです．

adefine(̀ user_canbe_sysadm')

bdefine(̀ ssh_sysadm_login')

これらの定義のセキュリティ上の問題点を以下

に示します．

●aの定義の問題点

aの定義により，一般ユーザでもsysadm_rにな

れますし，一般ユーザがsuを使うだけで，rootユ

ーザかつsysadm_rになることができます．一般ユ

ーザで sysadm_rになった段階では，uidは一般ユ

ーザですので，通常のLinuxのパーミッションチェ

ックが機能し，悪事はできません．

しかし，「ローカルexploit」という攻撃手法を使

うと，uidをrootにすることができます．こうなっ

てしまうと，悪意あるユーザがuid「root」かつロ

ール「sysadm_r」になることができ，悪事のし放

題になってしまいます．

●bの定義の問題点

bの定義により，「sshd（sshd_t）が/bin/bash

（shell_exec_t）を実行すると，/bin/bashが

sysadm_tで起動する」というドメイン遷移が許可

されていますが，このドメイン遷移は非常に危険

です．

というのも，次のようにsshdのセキュリティホー

ルを利用して，パスワードを知らない攻撃者が

sysadm_tドメインを乗っ取ることができるからです．

①sshdのセキュリティホールを利用し，攻撃者が

sshdを乗っ取ります．

本章では，前章までの知識を応用し，実際にWebサーバを構築／運用します．SELinuxのセキュリティ機能をフルに活用し，Apacheで静的なコンテンツを公開する方法／PukiWikiを例にPHPサイトを構築する方法／リモートから安全にWebサーバを管理する方法を紹介します．



サーバ用途に設定を調整

tunable.teのデフォルト定義が危険な理由

②攻撃者がシェルを実行注1します．

③sshd_tからドメイン遷移が起こり，

sysadm_tドメインでシェルが起動しま

す．

攻撃者はこのシェルを使えばやりたい放題でき

ます．

●コメントアウトする

以上の理由により，abの定義は問題があるこ

とがわかりました．これらの定義を，先頭に「dnl」

を付加してコメントアウトすることにより無効に

します．

dnl define(̀ user_canbe_sysadm')

dnl define(̀ ssh_sysadm_login')

この後，make reloadにより設定を反映します．

●設定の結果

tunable.teの調整前後で，どのように設定が変わ

ったのかを表1に示します．

一般ユーザはsysadm_rロールになれません．ま

た，suコマンドを使うこともできません．なぜな

ら，表1によると suコマンドを使うには staff_rか

sysadm_rロールになる必要がありますが，一般ユ

ーザはuser_rロールにしかなれないため，suコマ

ンドを使えないのです．

ただ，一般ユーザがsuを使えないと，リモート

管理のときに困る場合があります．限られた一般

ユーザだけsuを使えるようにする方法は，本章58

ページの「特定の一般ユーザから rootになれるよ

うにする」で後述します．

では，いよいよSELinux上でApacheを動作させて

みましょう．Apacheに関連する設定は整備されて

おり，とくに何も設定しなくともApacheは動作し

ます．

まず，Apacheを起動します．

# /etc/rc.d/init.d/httpd start

次に，Apacheのドメインを確認します（図1）．

Apache（/usr/sbin/httpd）には，httpd_tというド

メインが割り当てられていることがわかります．

●httpd_t

httpd_tはApacheが動作するのに必要な権限を持

ったドメインであり，表2のような権限を持ってい

ます．たとえば，httpd_tは，httpd_sys_content_tタ

イプを読み込み可能です．このタイプは，Webペ

ージに付与されたタイプですから，ApacheはWeb

ページを読むことができるわけです．

●Webページの公開方法

Webブラウザで，SELinuxマシンにアクセスす


調整前調整後

rootユーザが利用できるロール staff_r，sysadm_r 変更なし

一般ユーザが利用可能なロール user_r，sysadm_r user_rのみ利用可

suの利用すべてのロールで利用可 staff_r，sysadm_rロールのみ利用可※

SSHログインすべてのロールでログイン可能 staff_r，user_rでログイン可能

●表1 tunable.teの調整による設定の変化

※一般ユーザはuser_rロールにしかなれないので，suも使えなくなります

# ps -eZ

1535 system_u:system_r:httpd_t /usr/sbin/httpd

図1 Apacheのドメインを確認

httpd_t略

略

設定を調整 Apacheの構築

Webページの公開

注1）厳密に言うと，SELinux特有のシステムコールを使ってシェルを実行します．

れば，テストページを問題なく閲覧できます．静

的なコンテンツを配信するだけでしたら，

/var/www/htmlにHTMLファイルを置くだけで動

作します．

●別の場所にコンテンツを置くには

/ v a r /www/h tm l 以外の場所，たとえば

/var/www/hogeにコンテンツを格納する場合は，

「file_contexts/program/apache.fc」にリスト1のよ

うに記述し，設定を反映します．

# make reload

# setfiles file_contexts/file_contexts/

var/www （実際は1行）

CGIやPHPによる動的なWebページを見てみま

しょう．これらは，処理の内容によって必要な権

限が異なるため，設定の追加が必要になってきま

す．設定の追加は，3章の図2とまったく同じ手順

で追加します．

●CGI

CGIスクリプトは，「httpd_sys_script_t」という

ドメインで動作します．ApacheがCGIスクリプト

を起動するタイミングでドメイン遷移が起き，CGI

スクリプトにドメインが割り当てられます．

このドメイン遷移が起こるためには，CGIスク

リプトに「httpd_sys_script_exec_t」というタイプ

が付与されている必要があり，「/var/www/cgi-bin/」

にはこのタイプが付与されています．これ以外の

ディレクトリにCGIスクリプトを格納する場合に

は，CGIスクリプトにhttpd_sys_script_exec_tタイ

プを付与する必要があります．

●PHP

PHPのスクリプトは，Apacheと同じドメイン

「httpd_t」で動作します．本来は，PHPスクリプト

に独自のドメインを割り当てるのが望ましいので

すが，PHPの仕様上不可能です．というのも，ド

メイン遷移を起こすためにはプログラムを「exec

システムコール」を介して実行する必要があるの

ですが，PHPはApacheモジュールの内部で処理さ

れており，「execシステムコール」を介さずに実行

されています．したがって，PHPスクリプト実行

時にはドメイン遷移が起こらず，PHPスクリプト

は親プロセスApacheのドメイン「httpd_t」を引き

継いで動作します．

ここで，PHPの例として，代表的なWiki注2とし

て知られる「PukiWiki（http://pukiwiki.

org/）」を動作させてみましょう．今回は，

Oct. 2004 - 53

4章◆セキュアなWebサーバ構築＆管理マニュアル

アクセス権限タイプタイプが付与されているディレクトリ

読み込み httpd_sys_content_t /var/www（Webページ）

httpd_config_t /etc/httpd（Apache設定ファイル）

実行 httpd_sys_script_exec_t /var/www/cgi-bin（CGIファイル）

httpd_modules_t /usr/lib/httpd（Apacheモジュール）

追記 httpd_log_t /var/log/httpd（Apacheのアクセスログ）

書き込み httpd_cache_t /var/cache/mod_ssl（SSLの作業ファイル）

●表2 httpd_tドメインのおもなアクセス権限

/var/www/hoge(/.*)? system_u:object_r:httpd_sys_content_t

リスト1 apache.fcに記述

注2）Wikiとは，コンテンツを誰もが自由に共同編集することができるしくみです．Wikiを使ったページの代表例として，Wikipedia

（http://ja.wikipedia.org/wiki/）という百科事典サイトがあります．

動的なWebページ：CGIとPHP

PHPの例：PukiWikiを動作させる


PukiWiki 1.4.3を対象にします．

まず， P u k iW i k i のアーカイブファイル

（http://pukiwiki.sourceforge.jp/download

/pukiwiki1.4.3.tar.gz）をダウンロードしまし

ょう．

ダウンロードしたら，/var/www/htmlディレク

トリにて，このファイルを展開します．

# cp pukiwiki1.4.3.tar.gz /var/www/html

# cd /var/www/html

# tar xzvf pukiwiki1.4.3.tar.gz

/var/www/html/pukiwikiディレクトリ以下に，

PukiWikiの実体であるPHPスクリプトが展開され

ます．

この状態で，PukiWikiのフロントページにアク

セスしてみると，エラーが表示され，うまく動作

しません（図2）．

3章で行ったのと同じく，障害発生時にSELinux

の問題であるかどうかを切り分けるために，

permissiveモードにして動作テストを行ってみます．

試しに「編集」のリンクを辿って，ページを編

集してみると問題なく動作しますので，SELinuxの

設定の問題であることがわかります．

そこで，permissiveモードでPukiWikiを動作さ

せたときのログを調査し，どんな権限が足りない

かを把握します．PukiWikiはPHPスクリプトです

が，Apache（httpd）の内部で処理されているため，

プロセスの名前は「/usr/sbin/httpd」，ドメインは

「httpd_t」であることに注意してください．すると，

/var/www/wiki以下のファイル（httpd_sys_

content_t）を書き込み／生成（write／create）し

ようとして拒否されたログが出力されていること

がわかります．

3章の図2にあるとおり，ポリシファイルの設定

方法には簡易設定と安全な設定がありました．た

だし，今回のケースでは簡易設定を行うと，セキ

ュリティ上大きな問題があります．

簡易設定では，audit2allowで設定を生成していま

した．今回は図3のような設定が出力されます．こ

の設定は非常に危険です．なぜなら，httpd_sys_

content_tは/var/www/html以下のファイルすべての

ファイルのタイプであるので，httpd_tドメインが，

/var/www/html以下にあるすべてのファイルに対す

る書き込み権限を得てしまうからです．

このような設定をし，もしhttpdが攻撃者に乗っ

取られると，この書き込み権限を利用してWebペ

ージが改ざんされてしまうおそれがあります．

したがって，今回は簡易設定ではなく，3章の

「安全な設定法：タイプを付与して直接アクセス権

限を記述」（47ページ）の項で紹介した手順に従い

ます．

●ログのチェック

実際に，PukiWikiが書き込んでいるファイルを

調査してみると，/var/www/html/pukiwikiだけで

あることがわかります．よって，PukiWikiにはこ

●図2 デフォルトではPukiWikiはうまく動作しない

# audit2allow -d -lallow httpd_t httpd_sys_content_t:dir { add_name remove_name write };allow httpd_t httpd_sys_content_t:file { create unlink write };

●図3 今回audit2allowから出力されるallow文

Pukiwikiのインストール

問題切り分けとログのチェック

簡易設定では危険

安全な設定の手順

のディレクトリに対する書き込み権限を与えれば

良いことがわかります．

●設定を記述する

/var/www/html/pukiwiki以下のファイルに，

「wiki_write_t」というタイプを割り当て，httpd_tド

メインがwiki_write_tタイプに書き込めるような設

定を記述します．

今回の動作テストのログを見てみると，httpd_t

ドメインが，/var/www/pukiwiki以下にファイル

（オブジェクトクラス file）を生成（create）したロ

グが出力されています．3章の表5を参照すると，

「rw_dir_create_file」マクロを使い，wiki_write_tの

タイプが付与されたファイル／ディレクトリへの

書き込みおよびファイル生成権限を与えれば良い

ことがわかります．

結局，リスト2のような設定を記述することに

なります．なお，今回も作業ディレクトリは

「/etc/security/selinux/src/policy」です．

設定を記述したら，設定を反映します．

# make reload

# setfiles file_contexts/file_contexts /

var/www/html （実際は1行）

設定を反映したら，enforcingモー

ドに戻し，PukiWikiの動作テストを

再度行い，正しく動作することを確

認します．

Webalizerは，Fedora Core 2に標準添付されてい

る，Webサーバのアクセスログ解析ツールです．

アクセス数や，どのアドレスからのアクセスが多

いのかなどの情報を，グラフで表示することがで

きます．デフォルトではcronジョブ注3として1日1

回動作するようになっています．

Webalizerは，system_crond_tドメイン注4で動作

しますが，このままではsystem_crond_tドメイン

に権限が足りずに動作しません．これについても，

PukiWikiと同様に設定を追加できます．

●ログのチェック

permissiveモードで動作テストをしてみると，

Webalizer（system_crond_t）は，表3のようなファ

イル／ディレクトリにアクセスしていることがわ

かります．

Oct. 2004 - 55


アクセス権限アクセスしているそのディレクトリ／ファイルの

ディレクトリ／ファイルタイプ

読み込み /var/log/httpd httpd_log_t

/var/log/xferlog xferlog_t

書き込み／ファイル生成 /var/lib/webalizer var_lib_t

書き込み／ファイル生成 /var/www/usage httpd_sys_contents_t

●表3 Webalizer（system_crond_tドメイン）がアクセスしているディレクトリ／ファイル

/var/www/html/pukiwiki(/.*)? system_u:object_r:wiki_write_t

type wiki_write_t,file_type,sysadmfile;rw_dir_create_file(httpd_t,wiki_write_t)

●リスト2 追加した設定

注3）crondをコマンドラインから起動する場合「run_init /etc/rc.d/init.d/crond start」のように，起動コマンドの前に「run_init」を付与

する必要があります．run_initはSELinux拡張プログラムを起動するために使うコマンドです．crondはSELinux拡張されているため，

このコマンドを使って起動する必要があります．今のところ，run_initはcrondを起動するときにしか使いません．

注4）system_crond_tは，cronジョブのためのデフォルトのドメインです．

file_contexts/program/apache.fcに追加

domains/program/apache.teに追加

ログの解析 Webalizer

Webalizerとは

ただ，var_lib_t（/var/lib/webalizerのタイプ），

httpd_sys_content_t（/var/www/usageのタイプ）

に対する書き込みアクセス許可を与えると，これ

らのタイプはほかのファイル／ディレクトリにも

付与されているため，必要ないファイルへの書き

込みまで許してしまいます．よって，/var/lib/

webalizer，/var/www/usageには独自のタイプを付

与します．

●設定を記述する

これらを踏まえると，リスト3のような設定を追

加することになります．設定を追加したら，

# make reload


var （実際は1行）

にて設定を反映します．

●webalizer.confの変更

これでSELinux側の設定は終了ですが，Apache

側の設定で，webalizer.confにリスト4の枠囲みの

部分を追加しないと，結果をリモートから閲覧で

きません．また，usageディレクトリを不特定多数

の人に見せたくない場合はBasic認証をかけておく

と良いでしょう．

コンテンツを更新する場合，リモート管理が必

須になってきます．ここでは，サーバをリモート

から管理する方法を解説します．

本章冒頭の「サーバ用途に設定を調整」のとこ

ろで，SSHから直接sysadm_rになれないようにし

ています．そのため，SSHログインする場合は，

まず rootユーザでログインします．このときのロ

ールはstaff_rです．そのあと，「newrole -r sysadm_r」

でsysadm_rになることで管理を行います．

コンテンツをアップロードする場合には，FTP

を使うことは望ましくありません．なぜなら，

FTPではパスワードが平文でやりとりされるため，

パスワード盗聴のおそれがあるからです．そこで


/var/lib/webalizer(/.*)? system_u:object_r:webalizer_work_t/var/www/usage(/.*)? system_u:object_r:webalizer_usage_t

#/var/lib/webalizerへの読み書きファイル生成type webalizer_work_t,file_type,sysadmfile;rw_dir_create_file(system_crond_t,webalizer_work_t)

#/var/www/usageへの読み書きファイル生成type webalizer_usage_t,file_type,sysadmfile;rw_dir_create_file(system_crond_t,webalizer_usage_t)

#/var/log/xferlog,/var/log/httpdの読み込みr_dir_file(system_crond_t,xferlog_t)r_dir_file(system_crond_t,httpd_log_t)

#httpdが/var/www/usageにアクセスできるようにr_dir_file(httpd_t,webalizer_usage_t)

●リスト3 Webalizerを動作させるための設定（file_contexts/program/crond.fcおよびdomains/program/crond.te）

file_contexts/program/crond.fc

domains/program/crond.te

Webサーバのリモート管理

SSHによるリモート管理

SFTPによるコンテンツの転送

<Location /usage>Order deny,allowDeny from all#Allow from 127.0.0.1Allow from all

●リスト4 リモートからログ解析結果を見るためのwebalizer.confの変更箇所

Allow from all

略

今回は，「SFTP（Secure File Transfer Protocol）」と

いうSSH経由でファイルをアップロードするしく

みを利用します．

●SFTPの使い方

LinuxクライアントからSFTPを使うには，

sftp ユーザ名@ホスト名

で，リモートマシンにログインします．ログイン

した後は，通常のFTPとコマンドは同じです．

Windows側のクライアントとしては，WinSCPと

いうソフトがSFTPに対応しています．原稿執筆時

は，WinSCP3.6.7というバージョンが最新バージョ

ンです．http://winscp.sourceforge.net/

eng/download.phpの，「WinSCP 3.6.7 installation

package」をダウンロードし，実行すればインスト

ールできます．日本語対応するには，http://win

scp.sourceforge.net/eng/translations.php

の「Japanese」というところから，jp.zipというフ

ァイルを入手／展開し，WinSCP3.jpファイルを

WinSCPのインストールフォルダにコピーします．

操作も非常に簡単ですので，詳しい使い方は省略

します．

●コンテンツのアップロード

SFTPでログインすると，ユーザはデフォルトの

ロールでログインし，そのロールに対応した権限

でファイルを転送します．つまり，ユーザ名 root

でSFTPログインした場合，ロールはstaff_rロール

です．このロールに対応した権限は「staff_tドメイ

ン」ですから，staff_tドメインの権限でファイルを

転送できます．

ただし，staff_tドメインは，/var/wwwへのアク

セス権限を持ちませんので，SFTPで直接コンテン

ツを/var/wwwにアップすることはできません．い

ったん，ホームディレクトリにコンテンツを転送

した後に，SSHで rootユーザ，sysadm_rロールで

ログインすることで，ホームディレクトリに転送

したコンテンツを/var/wwwにコピーします．

●「̃/.ssh」についての注意

SSHで，公開鍵を利用した認証を行う場合，ホ

ームディレクトリの下に「.ssh」というディレクト

リを作成し，鍵ファイルを配置します．.sshを新

規作成した時点では，適切なタイプが付与されな

いため，sshdは鍵ファイルを閲覧できず，うまく

動作しません．.sshファイルにタイプを付与しな

おすため，


home （実際は1行）

とする必要があります．

ここまでの方法で，リモート管理を行うことが

できますが，このままでは不安が残ります．なぜ

なら，rootユーザの認証情報（パスワードなど）

が，第三者に判明してしまったら，第三者に root

かつsysadm_rロールで不正ログインされてしまう

からです．

そこで，SELinux側の設定を工夫し，rootユーザ

で直接ログインできなくすれば，この心配は解消

されます注5．

●rootユーザで直接ログインできなくする

方法は簡単です．「/etc/security/selinux/

src/policy/users」注6の，リスト5（rootユーザは

staff_r，sysadm_rを使えるという意味）の行から，

枠で囲んである「staff_r」を削ります．これで，

rootユーザはstaff_rロールが使えなくなります．

make reloadして設定を反映すれば，rootでSSH

でログインしようとしてもエラーになります．な

ぜなら，SSHからは staff_rロールでしかログイン

できないようになっていますが，さきほど行った

設定により rootユーザは staff_rロールを使えなく

なっており，ログインできないからです．

Oct. 2004 - 57


注5）sshデーモン側の設定（/etc/ssh/sshd_config）でも，rootユーザでログインできなくすることはできますが，SSHにセキュリティホ

ールがあった場合はrootでログインできない設定が回避されてしまうおそれがあります．

注6）ユーザがどんなロールを利用可能か記述されているファイルです．

リモート管理をより安全にする

この設定の副作用として，make relabelをする際

にエラーが出てしまいます．これを回避するため

には，file_contexts/program/apache.fcから，リスト

6の行を削除するかコメントアウトすればOKです．

●特定の一般ユーザからrootになれるようにする

rootで直接ログインできなくなったので，いっ

たん一般ユーザでログインした後，suコマンドを

使って，rootユーザかつsysadm_rになる必要があ

ります．しかし，「設定を調整」の項で，一般ユー

ザがsuコマンドを使えないように設定しています．

今回は，遠隔管理のために，「一般ユーザ

ynakamだけはsuコマンドを使えるようにする」設

定を行います．

一般ユーザは「user_r」ロールでしかログインで

きませんでした．しかし，表1を見るとわかるとお

り，user_rロールではsuを使えません．suを使う

ためには，staff_rロールでログインできるようにす

る必要があります．

このために，/etc/security/selinux/src/policy/

usersに

user ynakam roles { staff_r };

と追加します．これは，「ユーザynakamはstaff_r

が利用可能」という意味です．

make reloadで設定を反映し，さらに/homeディ

レクトリ以下のタイプも変わっているため

setfiles file_contexts/file_contexs /ho

me/ynakam （実際は1行）

を実行し，タイプを付け直します．

●実際の運用方法

これで，ユーザynakamが，suを使えるようにな

ります．ほかの一般ユーザはsuを使うことはでき

ません．SSHで管理をする場合は，いったんユー

ザ名ynakamでログインし，suにより，rootユーザ，

sysadm_rロールでログインします（図4）．このよ

うにしておけば，攻撃者がrootかつsysadm_rロー

ルで不正ログインするためには，ユーザynakamと

rootのパスワード両方を知る必要があるため，不

正ログインがより難しくなります．

Webページをアップロードするときは，SFTPで

ユーザ名ynakamでログインし，ファイルを転送し

た後，SSHでynakamでログイン，suしてから転送

したファイルを/var/wwwにコピーします．

SELinuxを使ったWebサーバ構築方法の解説は

ここで終わります．ここまでで解説した知識で，

sendmailを使ったメールサーバやBINDを使ったネ

ームサーバの構築にも応用できますので，ぜひチ

ャレンジしてください．s


user root roles { staff_r sysadm_r ifdef(̀ direct_sysadm_daemon', ̀ system_r') };

●リスト5 rootユーザがstaff_rを使用できないようにする

staff_r

↑ここを削除

HOME_DIR/((www)|(web)|(public_html))(/.+)? system_u:object_r:httpd_ROLE_content_t

●リスト6 apache.fcから以下の行を削除

[ynakam@localhost ynakam]$ getconynakam:staff_r:staff_t[ynakam@localhost ynakam]$ suPassword:Your default context is root:sysadm_r:sysadm_t.

Do you want to choose a different one? [n] [root@localhost ynakam]# getconroot:sysadm_r:sysadm_t

●図4 いったん一般ユーザでログインし，リモート管理を行っている様子

ユーザ名ynakam，ロールstaff_rでログインしている

•でsysadm_rでログイン

ユーザ名root，ロールsysadm_rでログインしている

ynakamはsuコマンドを使うことができるrootユーザのパスワード入力

デフォルトのロールはsysadm_r

終わりに

Oct. 2004 - 59

かつてのSELinuxは，カーネルにパッチを当て

る必要があったため，インストールが大変で，ユ

ーザが使うための敷居が高いものでした．

2001年3月，Linux Kernel Summitにて，SELinux

の開発者がSELinuxのプレゼンテーションを行っ

た際，Linuxの創始者であるLinus Torvaldsを交え，

SELinuxをLinuxカーネル本流（当時はカーネル

2.5）に取り込むにはどうしたら良いかという議論

が行われました注1．

当時，Linux上のセキュアOSはSELinux以外に

もさまざまなものがリリースされていましたが，

Linus氏はどれか1つを特別扱いする気はなく，「さ

まざまなセキュリティ機能をカーネルモジュール

として実装できるしくみならばLinuxカーネル本流

に入れても良い」との意思を表明しました．

そこで注目されたのが，WireX Communications

（現 Immunix．http://www.wirex.com/）によっ

て立ち上げられていた「LSM（Linux Security

Modules）」です．

LSMは，さまざまなセキュリティ機能をカーネ

ルモジュールとして実装するためのフレームワー

クです注2．LSMを使用すれば，簡単にセキュアOS

を実装することができますし，ユーザは，LSMに

準拠したセキュアOSモジュールを好みに応じて選

択することができます．

その後LSMは，カーネル2.6に取り込まれまし

た．現在LSMに従って実装されたセキュアOSに

は，「SELinux」「LIDS」「DTE」「Openwall」などが

あります．そして，LSMがカーネル本流に組み込

まれた甲斐あって，SELinuxもカーネル2.6に取り

込まれました．今後，ほかのセキュアOSもLinux

カーネル本流に取り込まれていくと思われます．

では，LSMを詳しく見ていきましょう．LSMの

しくみを説明するため，本特集1章で掲載した図を

Linuxカーネル2.6になり，SELinuxはカーネルに取り込まれました．その大きなきっかけとなったのが「LSM（Linux Security Modules）」がカーネル2.6へ採用されたことです．ここでは，LinuxのセキュアOSを語るうえで欠かせないLSMを紹介します．



注1）このときの議論の一部はLSMのメーリングリストのアーカイブに残っています．http://mail.wirex.com/pipermail/linux-security-

module/2001-April/0005.html

注2）当時のLinuxカーネル2.4でもセキュアOSをモジュールとして実装することも不可能ではないですが，実装は大変ですし，機能も限

定されます．

LSM登場の経緯

セキュアOSを楽に実装できるように

LSMがカーネルに

LSMのしくみ

再掲します（図1）．順を追ってLSMの動きを見て

みます．

①プロセスは，リソースにアクセスをする際に，

まず，カーネルにアクセス要求を出します．

②通常のパーミッションチェックが行われます．

ここまでは普通のLinuxと同じです．

③LSMにアクセス要求が渡ります．

④LSMからセキュアOSのモジュールにセキュリ

ティチェック要求が渡ります．

⑤セキュアOSモジュールの中で，各セキュアOS

独自のセキュリティチェックが行われます．

⑥セキュアOSモジュールはセキュリティチェック

の結果を返します．

⑦セキュリティチェックがOKのときだけ，リソー

スにアクセスをします．

LSMでは，④⑥のインターフェースの規定をし

ています．このインターフェースを統一すること

で，さまざまなセキュアOSを取り込めるようにし

ています．

①のインターフェースは通常のLinuxと同じで

す．このおかげで，通常のLinux用に作られたプロ

グラムをセキュアOS上で動かす場合にも，バイナ

リレベルで互換性があります．

LSMをさらに深く知るために，LSMの実装をカ

ーネル2.6.7のソースコードを例として紹介します．

カーネルコンパイル時に「Security-Options→

Enable different security models(CONFIG_SECUR

ITY)」を有効にすると，カーネルにLSMが組み込

まれます．LSMによる，カーネルの拡張は以下の

2点です．

¡データ構造の拡張

¡LSMフック関数の挿入

プロセス／リソースに関する構造体の中に，セ

キュリティ属性を格納するためのエントリが追加

されています．

●プロセス

プロセスに関する情報を格納する構造体

「task_struct」構造体には，「void *security」という

エントリがあります（リスト1）．このエントリに

は，プロセスに関するセキュリティ属性を格納し

ます．セキュリティ属性には，たとえばSELinux

のドメインがあります．


②Linuxパーミッション　チェック

③LSM ⑤セキュアOS 　モジュール

プロセス

①アクセス要求

④セキュリティ　チェック依頼

⑥チェック結果

⑦アクセスセキュリティポリシ

リソース

セキュリティ管理者のみが設定可能

rootでも回避できないセキュリティチェック

Linuxカーネル

●図1 LSMのしくみ（再掲）

LSMの実装を見る

データ構造の拡張

●リソース

リソースの例として，ファイルに関する情報を

格納する構造体「inode」構造体を見てみると，

「void *i_security」というエントリが存在します

（リスト2）．このエントリを使うことで，ファイル

にラベル付けすることができます．

●ソケット

ソケットに関する構造体 sockにも「 vo i d

*sk_security」というエントリが存在し，ラベル付

けすることができます．

◆◆◆

これらの以外にも，プロセス間通信，共有メモ

リにもラベル付けすることができます．

システムコールのソースコードにはLSMフック

関数が挿入されており，セキュリティチェックを

拡張できるようになっています．フック関数とは，

関数ポインタのことです．

●フック関数の種類

どんなフック関数が用意されているかは，

「security_operations」構造体に記述されています

（リスト3②）．たとえば，「inode_mkdir」というフ

ック関数は，ディレクトリ生成のセキュリティチ

ェックを行うために用い，「socket_create」フック

関数は，ソケット生成のセキュリティチェックを

行うために使います．

関数ポインタの指す先を変えることによって，

セキュアOSを切り替えることができます．たとえ

ば，inode_mkdirをSELinuxのセキュリティチェッ

ク関数を指すようにすれば，ディレクトリ生成時

に，SELinuxのセキュリティチェックを行うように

なりますし，この関数ポインタの参照先をLIDSの

セキュリティチェック関数にすれば，LIDSのセキ

ュリティチェックが行われるようになります．

また，リスト3①のようにsecurity_operations型

の「security_ops」という変数が用意されており，

実際にはこの変数を使ってLSMフック関数がシス

テムコールのソースの中に挿入されています．リス

ト4は，LSMフック関数が挿入されている例です．

●具体例

リスト4は，mkdirシステムコール（ディレクト

リを生成するシステムコール）のソースです．シ

ステムコールが呼び出されるとまず，

①普通のLinuxパーミッションチェックが行われま

す．

Oct. 2004 - 61

App.1◆LSMを理解する

extern struct security_operations *security_ops;

struct security_operations {

int (*inode_mkdir) (struct inode *dir, struct dentry *dentry, int mode);

int (*socket_create) (int family, int type, int protocol);

}

●リスト3 LSMフック関数（include/linux/security.h）

略

略

略

①

②

struct inode {struct hlist_node i_hash;

atomic_t i_writecount;void *i_security;__u32 i_generation;

};

●リスト2 ファイルに関する情報を格納するinode構造体（include/linux/fs.h）

略

略

void *i_security;

struct task_struct {

sigset_t *notifier_mask;void *security;struct audit_context *audit_context;

/* Thread group tracking */u32 parent_exec_id;

};

●リスト1 プロセス情報を格納するtask_struct構造体（include/linux/sched.h）

略

略

LSMフック関数の挿入

②フック関数を使ってセキュリティチェック関数

を呼び出します．inode_mkdirがSELinuxのセキ

ュリティチェック関数を指していれば，SELinux

のセキュリティチェックが呼び出されます．

③これらのチェックが通ると，実際にディレクト

リを作る操作が行われます．

LSMのフック関数がシステムコールのソースに

挿入されているだけでは意味がなく，そのフック

関数からセキュアOSのチェック処理が呼び出され

るようになっている必要があります．そのために

は，セキュアOSのセキュリティチェック関数を登

録する必要があります．

登録処理の様子をSELinuxを例にして見てみま

す．SELinuxには独自のセキュリティチェック関数

が用意されており，これらは，security/selinux/

hooks.cファイルの中に記述されています（リスト

5）．リスト5①は，mkdirシステムコールのセキュ

リティチェックを強化するための，SELinuxのセキ

ュリティチェック関数です．この中の

「may_create」という部分で，SELinux独自の処理

を行っています．リスト5②は，SELinuxのセキュ

リティチェック関数をまとめて格納する変数

「selinux_ops」です．SELinuxのセキュリティチェ

ック関数は必ず，「selinux_ops->チェック関数の名

前」のようにして呼び出されます．

●実際の登録の様子

これらのセキュリティチェック関数は，リスト6

のようにして登録されます．リスト6①はSELinux

の初期化時に呼び出される selinux_init関数です．

この初期化時のregister_security関数の中で，②の

ように，LSMフック関数を格納している変数

security_opsがselinux_opsで上書きされます．

これにより，SELinuxのセキュリティチェック関

数が登録されました．リスト4②の場合に戻ってみ

てみると，「security_ops->inode_mkdir」が指す先

は，「selinux_ops->inode_mkdir」になっています．

つまり，リスト5①のSELinux独自のチェック処理


注3）ちなみに，SELinuxを登録する前のsecurity_opsは，何も処理をしないダミーの関数を示すようになっています．

int vfs_mkdir(struct inode *dir, struct dentry *dentry, int mode){

int error = may_create(dir, dentry, NULL);if (error)

return error;

error = security_ops->inode_mkdir (dir, dentry, mode);

if (error)return error;

DQUOT_INIT(dir);error = dir->i_op->mkdir(dir, dentry, mode);

}

●リスト4 LSMフック関数が挿入されている様子（fs/namei.c）

略

①

②

③

※②は実際には「error = security_inode_mkdir(dir, dentry, mode);」と記述されています．「security_inode_mkdir」はinclude/linux/security.hで定義されているマクロです．②には見やすさのため，マクロを展開したものを記述しています．

static int selinux_inode_mkdir(struct inode *dir,struct dentry *dentry, int mask){

return may_create(dir, dentry, SECCLASS_DIR);}

struct security_operations selinux_ops = {略.inode_mkdir = selinux_inode_mkdir,.socket_create = selinux_socket_create,

略}

●リスト5 SELinuxのセキュリティチェック関数（security/selinux/hooks.c）

略

①

②

※②は，struct security_operations selinux_ops;selinux_ops.inode.mkdir = selinux_inode_mkdir;selinux_ops.socket_create = selinux_socket_create;と同じ意味です．

略

SELinuxのセキュリティチェック関数

が呼び出されるようになってい

ます注3．

LSMがLinux本流に取り込まれ

たことにより，セキュアOS導入

の敷居が大幅に下がりました．しかし，LSMは良

いことばかりではなく，LKM rootkit作成を容易に

してしまう，という問題点があります．rootkitと

は，攻撃者が不正侵入した際に使うツールのこと

で，バックドア／トロイの木馬／ログ消去ツール

などから構成されています．LKM rootkitとは，カ

ーネルモジュールとして機能するrootkitです．

●比較的簡単に作成できてしまう

LSMのフック関数は，セキュリティ上の要所要

所に挿入されています．しかし，LKM rootkitを作

る側から見てみれば，セキュリティの要所要所で

悪さをできる，ということになります．しかも，

LSMのフック関数の指す先を，悪意のある処理を

行う関数にするだけで良いのですから，カーネル

モジュールとして簡単に作れてしまいます．

●影響を受ける環境

ただし，このことはセキュアOSを使っている場

合は大きな問題にはなりません．セキュアOSはモ

ジュールのインストールを禁止できますので，た

とえ攻撃者がLSMを使ったrootkitをインストール

しようとしても，インストールに失敗します．

問題になる場合は，LSMは有効にしているが，

セキュアOSのモジュールを組み込んでいない場合

です．Fedora Core 2のデフォルトの状態がこれに

当たります．

◆◆◆

今のところ，LSMを使ったrootkitは出現していま

せん．しかし，カーネル2.6の普及とともに出現す

る可能性は十分にあります．今後，セキュアOSを

使っていない場合はLSMのフック関数を使えなく

できるようなしくみが必要になってくるでしょう．

LSMによって，セキュアOSの実装が簡単になり

ましたし，同時に入出力をチェックするようなセ

キュリティソフトウェアの実装も簡単になってい

ます．今後は，LSMに対応したセキュリティソフ

トウェアの増大も予想されます．実際に，ウィル

スチェックソフトの中にはLSMを使っているもの

も現れ始めています．

こうなってくると，たとえばSELinuxとウィル

スチェックを同時に使いたい，というように複数

のLSMモジュールを同時に使う場合が発生してき

ます．しかし，LSMはLSMモジュール共存を十分

にサポートしておらず，このような共存は不可能

です．今後の対応が待たれるところです．

LSMを通じて，セキュアOSの実装の骨格を見て

みました．本稿を見てわかるように，LSM自体は

非常に単純な構造です．独自のLSMモジュールを

作ることも，さほど難しいものではありません．

その際，「Realtime LSM（http://www.joq.us/

realtime/）」というLSMモジュールは，規模も

小さく，参考となると思います．ぜひLSMモジュ

ールの作成にチャレンジしてみてください．s

Oct. 2004 - 63

App.1◆LSMを理解する

__init int selinux_init(void){

if (register_security (&selinux_ops))panic("SELinux: Unable to register with kernel.\n");

int register_security (struct security_operations *ops){

security_ops = ops;

●リスト6 SELinuxのセキュリティチェック関数の登録の様子

略

略

略①

②

略

security/selinux/hooks.c

security/security.c

LSMの課題

LKM rootkit

LSMモジュール共存の問題

終わりに

SELinuxの最新動向をウォッチする場合，コミュ

ニティの動向をチェックするのが一番です．ここ

では，SELinux開発元のコミュニティと，国内コミ

ュニティを紹介します．

SELinuxは，元々はNSA，Secure Computing，

MITRE，NAI Labsを中心として開発されましたが，

現在はNSAとRed Hat,Inc.を中心としたコアメンバ

で開発されています．SELinuxはオープンソースな

のですが，開発コアメンバはオープンには募集さ

れていないようです．SELinuxの開発に関わりたい

場合は，メーリングリストを通じてパッチやポリ

シを提出して，コアメンバに承認されるのを待つ

しかないようです．

●開発メーリングリスト

SELinuxの最新動向を知りたいときや，パッチ／

新機能の提案をしたいときは，メーリングリスト

を利用します．

SELinuxの開発に関するメーリングリストは2つ

あります．

1つ目は，開発元のNSAのメーリングリスト

（http://www.nsa.gov/selinux/）です．こち

らは，SELinuxに関する全般的な話題を扱ってお

り，新機能についての議論やアナウンスが行われ

ます．

もう 1つは，fedora-selinuxメーリングリスト

（http://www.redhat.com/mailman/listinfo/

fedora-selinux-list/）です．こちらは，

Fedora CoreのSELinuxに特化したメーリングリス

トですが，最近はFedora Coreで開発された機能が

開発元にフィードバックされることも多くなって

いますので，こちらのメーリングリストに加入し

ておくこともお勧めします．

●開発コアメンバ

SELinuxの開発コアメンバは誰であるのかは，公

表されていませんが，メーリングリストを見てい

ると，コアメンバが誰であるかを推測することが

できます．

コアメンバと思われる人たちの中でも，とくに

注目すべき人々を表1で紹介します．彼らの発言に

注目しておけば，SELinuxの動向を追うのが楽にな

ります．また，パッチを提出するときも彼らにCC

しておくと良いでしょう．


このパートでは，SELinuxの最新の動向紹介として，SELinuxのコミュニティおよび企業の取り組みとともに，最新の機能を紹介します．



SELinuxコミュニティ

開発コミュニティ

日本国内でのSELinuxの普及を目指し，趣味面

のコミュニティと，ビジネス面のコミュニティが

設立されています．

●日本SELinuxユーザ会

SELinuxの普及およびユーザ同士の交流／情報交

換を目指し，非営利／中立の「SELinuxユーザ会」

が国内で準備中です．こちらは趣味／ボランティ

アベースで運営されているコミュニティです．

Webページ（http://www.selinux.gr.jp/）と

メーリングリスト（http://www.selinux.

hitachi-sk.co.jp/ml/ml-selinux-users-

ml.html）を活動の拠点としています．

オフラインでの活動としては，オフ会／勉強会

を不定期に開催しています．SELinuxを本格的に使

ってみたい場合は，ぜひメーリングリストに加入

してみてはいかがでしょうか．

●SELinux専門委員会

NPO日本オープンソース推進機構（JOSAO，

http://www.josao.jp/）の中に「SELinux専門

委員会」が設立されました．こちらは，SELinuxの

ビジネス面での普及を目指したコミュニティです．

オープンソース／セキュリティの専門家を中心と

した専門委員が，自治体／企業などのエンドユー

ザの立場から，SELinux普及のための議論を重ねて

います．今後は，エンドユーザのための提言や，

実証実験などを行っていく予定です．

国内企業でも，SELinuxに関する取り組みが始ま

ってきています．今のところ，SELinuxに取り組ん

でいるおもな企業は表2のとおりです．研究開発が

中心ですが，SIや教育のようなビジネスも始まり

つつあります．

Oct. 2004 - 65

App.2◆SELinuxの最新動向

メンバ名おもな担当

Stephen Smalley氏SELinux全般の開発に携わっています．この表のメンバの中では最も古くからSELinuxに関

わっています．

SELinuxのポリシ周りに注力しています．彼独自のポリシを持っており，彼のポリシに

Russell Coker氏パッチが取り込まれると，その後本家に取り込まれる流れになっているようです．ポリシに

関する議論は彼にCCすると話が早いです．

Daniel J Walsh氏 Red Hat,Inc.のSELinuxリーダー．Fedora CoreのSELinuxに注力しています．

James Morris氏SELinuxのカーネル部分を扱っています．SELinuxカーネルの新機能は，彼からアナウンス

されることが多いです．

●表1 SELinux開発コアメンバと思われる人々

企業名 SELinuxへの取り組み参考URL

日立ソフトウェア SELinux構築／運用ツールの開発／公開，http://www.selinux.hitachi-sk.co.jp/

エンジニアリング SELinuxシステム構築サービスの提供

NTTデータ SELinux拡張機能の開発 http://lc.linux.or.jp/lc2004/（講演内容）

日本高信頼システム（JTS）教育サービスの提供 http://www.jtsl.co.jp/

日本総合研究所（JRI）監査機能強化モジュールLBSM

http://sourceforge.jp/projects/lbsm/（Linux Basic Security Modules）の開発

●表2 国内企業の取り組み

国内SELinuxコミュニティ

企業の動向

国内企業の動向

SELinuxがカーネル2.6に取り込まれたこともあ

り，ディストリビューションでの取り込みも始ま

っています．表3がSELinux対応が進んでいるディ

ストリビューションです．無償／商用の主要ディ

ストリビューションで対応が進んでいることがわ

かります．とくに，商用ディストリビューション

でのサポートが始まってくる2004年秋～2005年初

頭になりますと，いよいよSELinuxの本格普及が

始まると予想されます．

SELinux本家では活発に開発が続いており，

Fedora Core 3などの新しいディストリビューショ

ンには新機能が取り込まれていくと予想されます．

その中でも，とくに重要になると思われる新機能

を紹介します．

現在，ポリシは「/etc/security/selinux/src」以

下に格納されたポリシ1種類しか用意されていま

せん．しかし，今後は，さまざまなポリシを選べ

るようになります．たとえば，2004年7月12日に

リリースされたFedora Core 3 test1では，「targeted

（使いやすさを重視したポリシ）」と「strict（安全

性を重視したポリシ）」という2種類のポリシを選

べるようになっています．

そして，それに伴いポリシの格納場所が変更さ

れ，「/etc/selinux/ポリシの種類」というディレク

トリに格納されるようになっています．

どのポリシを使うのかは，/etc/sysconfig/selinux

に，「SELINUXTYPE=」という要素で指定します．

たとえば「SELINUXTYPE=strict」と記述すれば，

「strict」のポリシを選択したことになり，/etc/

selinux/strict以下に格納されたポリシが使われま

す．

SELinuxのポリシを変更するためには，ポリシフ

ァイルの記述を変更し，make reloadする必要があ

りましたが，状況に応じて，すばやくポリシを変

更したい場合もあります．たとえば，攻撃の兆候

がある場合に，リモートからの重要なファイルへ

のアクセスを禁止するといった場合です．

●Conditional policy extension

「Conditional policy extension」という機能を使う

ことにより，すばやくポリシを切り替えることが

できます．この機能は，登場してから日が浅く，

Fedora Core 2では実験的に使われるに留まってい

ます．

Conditional policy extensionでは，フラグを使っ

て，フラグが1の場合は設定を有効にし，フラグが

0の場合は設定を無効にします．Fedora Core 2の場

合，「user_ping」というフラグが用意されています．

このフラグを使うことにより，「user_r，staff_rロ


形態ディストリビューション SELinux対応状況

Fedora Core Fedora Core 2で完全に対応済み

無償 Debian GNU/Linux 一部対応．既存パッケージとの依存関係が未解決

Gentoo Linux 多少バグはあるものの，積極的な対応

Red Hat Enterprise Linux 2005年初頭にリリースされるバージョン4で対応を表明

商用SuSE Linux SuSE Linux 9.1のカーネルでSELinux有効．正式なサポートはまだ行っていない

Turbolinux 2004年秋リリースの新サーバディストリビューション（コードネーム“Celica”）

よりサポート予定

●表3 SELinuxの対応が始まっているディストリビューション

ディストリビューションの動向

最新機能紹介

ポリシの選択

ポリシをすばやく切り替える

ールのpingコマンドの利用」を許可／拒否を動的

に切り替えることができます．

実際に，ポリシファイルの中でuser_pingフラグ

が使われている部分をリスト1に抜粋します．「{}」

に囲まれた中で，user_r，staff_rロールがpingを使

うための権限が設定されています．user_pingフラ

グが1の場合は，{}内の設定が有効，つまりuser_r，

staff_rがpingを使えるようになります．user_ping

フラグが 0の場合は，{}内の設定が無効になり，

user_r，staff_rはpingを使えなくなります．

●フラグの切り替え方

フラグを切り替えるためには，sysadm_rロール

で「change_bool」コマンドを使います．

# change_bool user_ping 1

とすれば，user_pingフラグが 1になり，user_r，

staff_rはpingを使うことができます．

# change_bool user_ping 0

で，user_pingフラグが0になり，user_r，staff_rで

pingを使おうとしてもエラーになります．

フラグの状態を見るには「show_bools」コマン

ドを使います．s

Oct. 2004 - 67

App.2◆SELinuxの最新動向

if (user_ping) {domain_auto_trans(unpriv_userdomain, ping_exec_t, ping_t)# allow access to the terminalallow ping_t { ttyfile ptyfile }:chr_file rw_file_perms;ifdef(̀ gnome-pty-helper.te', ̀ allow ping_t gphdomain:fd use;')

}

●リスト1 user_pingフラグが使われている部分

staff_r，user_rロールがpingを使うために必要な権限設定

先生とパソコン先生とパソコン

政府によるミレニアムプロジェクト「教育の情報化」により，学校教育の現場にも IT化の波が押し寄せてきました．『先生とパソコン』は，小中高等学校の先生向けに，授業／校務でパソコンを活用するためのノウハウをまとめた情報誌です．パソコンを使った授業のアイディア，授業で使えるソフトウェアやホームページの紹介，成績処理や事務処理などに便利なソフトウェアの活用法など，読めばすぐに役立つ内容を幅広く取り上げています．

【特集】楽しい授業，役立つ授業

学校でパソコンをもっと活用する【第2特集】先生知ってますか？

インターネットの良い点／悪い点再確認【第3特集】授業で使える！すぐに役立つ！

厳選教育ホームページ紹介ほか

体裁：B5判，192ページ＋CD-ROM×1定価：1,780円＋税ISBN ：4-7741-2092-8

好評発売中

付録CD-ROM×1

多言語化Squeak Ver.6.1 ほか収録

SDでもおなじみ，

Squeakインストール

CDが

付いた，お得な1

冊！

LIDS（Linux Intrusion Detection System）は，

SELinuxと同じく，無償のセキュアOS実装の1種

です．LIDSは，システムを保護するという機能を

備えながら，設定方法が非常に直感的で簡単であ

るという特色を持っています．この LIDSは，

Linuxカーネルにパッチを当てる形で提供されてい

ます．

最初のバージョンは，'99年にカーネル2.2用とし

て，Xie Huagang氏とPhilippe Biondi氏によってリ

リースされました．その後，カーネルのバージョ

ンアップとともに開発が進み，現在ではカーネル

2.4用のLIDS-1系列と，カーネル2.6用のLIDS-2系

列とに分かれています注1．

セキュアOSの代表である（おそらく，今一番メ

ジャーな）SELinuxとLIDSとは，どう違うのでし

ょうか．比較してみましょう．

LIDSとSELinuxとの違いを表1にまとめました．

SELinuxとのおもな相違点は，

¡ロールがない

ユーザごとにロールを決め，できることを限定

するような機能がありません．この点は，SELinux

に比べてはっきりと弱点になっているところです．

¡設定が簡単

のちほど説明しますが，LIDSでアクセス制限を

設定する方法は「どのプログラムが，どのオブジェ

クトに対して，どういうパーミッションを持ってい

る」という構文のコマンドを並べたリスト形式にな


本章では，SELinux以外のセキュアOSとして，LIDSを取り上げます．SELinuxほど高度な機能は持っていませんが，設定が直感的で非常にわかりやすいので，セキュアOSを初めて学ぶ方には最適だと思います．

日本SELinuxユーザ会準備委員会 LIDS支部面和毅OMO Kazuki ●[email protected]


注1）カーネル2.2用のものは，残念ながら開発がストップしました．

■機能面の比較 LIDS SELinux

ファイルのACL ○ ○

ロールの管理 × ○

プロセスのACL ○ ◎

ドメイン遷移 ○ ○

LSMとの連携 ○ ○

■サポート面の比較 LIDS SELinux

カーネルとの連携 △ ◎

ディストリビューションとの連携 △ ◎

情報源 △ ○

コミュニティの取り組み ○ ○

コミュニティの親密性 ◎ ○

●表1 LIDSとSELinuxとの違い

LIDSの紹介

SELinuxとLIDSの比較

っているため，非常に直感的です．また，構文が

iptablesに似ているため，親しみやすいと思います．

¡カーネルとの連携

カーネル 2.6にLSMが導入されたことにより，

さまざまなセキュリティモデルが組み込めるよう

になりました．その中でも，SELinuxはカーネル

2.6に標準で組み込まれていますが，LIDSはまだ組

み込まれておらず，カーネルにパッチを当てる形

式になっています．

最近ではLIDSもLSMに対応したため，今後は

カーネルに対するパッチではなく，モジュールと

して単独でコンパイルできるようにしようという

意見も出ています．

¡ディストリビューションとの連携

SELinuxは，Red Hat LinuxやTurbolinuxなど，

さまざまなディストリビューションに取り込まれ

ていますが，LIDSは，まだディストリビューショ

ンに取り込まれていません．

¡コミュニティの相違

LIDSは，完全にコミュニティベースで開発が進

められているため，個人の要望が聞き届けられや

すいと言えます注2．

◆◆◆

以上の点から，LIDSはSELinuxに比べて設定が

粗い反面，より直感的でわかりやすい設定方法を

提供していると言えます．

では，LIDSを導入するとシステムはどう変化す

るのでしょうか．LIDSを導入すると，システム上

では次の2種類のアクセス制御が可能になります．

①ファイルに対するアクセス制御

②プロセスに対してのアクセス制御

LIDSでは，システム内にすべてのアクセス制御

を書いたリストがあり，これを ACL（Access

Control List）と呼びます．そのACLの中で，とく

にファイルに関してのアクセス制御を書いている

部分を「ファイルACL」，特権に関するアクセス制

御を書いている部分を「権限ACL」と呼びます．

では，それぞれのアクセス制御について見てい

きましょう．

LIDS導入前は，システムは伝統的なUNIXパー

ミッション（rwxで表される設定です）を用いてア

クセス制御を行っています（図1）．

これに対し，LIDSを導入すると，システムは伝

統的なパーミッションによるアクセス制御を行っ

た後に，LSMを通じてLIDS独自のパーミッション

によるアクセス制御が行われます（図2）．これに

より，UNIXパーミッションで許可されている書き

込み行為を，LIDSのアクセス制御で禁止したりす

ることができます．

●LIDSで作成したパーミッションの特徴

LIDSで作成したパーミッションに関しては，

MAC（強制アクセス制御）で，次のような特色を

持っています．

Oct. 2004 - 69

5章◆他のセキュアOSの選択肢～LIDSの紹介

動作が許可される

動作の拒否

動作を許可するか？

No

Yes

プログラム

UNIXパーミッション -rwxr-xr-x root root

●図1 通常のLinux上でのプログラムの権限チェック

注2）この点は，SELinuxに比べて優位なところです:)．

LIDSを導入した場合のシステムの挙動

①ファイルアクセス制御

Linuxの場合

LIDSの場合

¡ディレクトリの所有者でもその内容を変更する

ことはできません．

¡このパーミッションを変更するためには，シス

テムを再起動してパラメータを指定して起動し

た後に，root権限でパーミッションを変更しな

くてはなりません．

¡rootでさえも，このパーミッションチェックを回

避する方法はありません．このため，rootに対

しても読み書きなどのアクセス制御を設定する

ことができます．

以上により，rootができることをなるべく少な

くし，一般ユーザに近いレベルまで下げることが

できます．したがって，システムが攻撃に遭い，

root権限を剥奪されたとしても，被害を最小限に

することが可能です．

●LIDSでのファイルACLの設定方法

LIDSでのファイルACLの設定は，

①すべてのプログラムに対してのデフォルトのフ

ァイルACLを設定する

②特定のプログラムに対して，個別にできること

を設定していく

というステップで行っていきます．

●ファイルACLによる制限の順番

ファイルACLを設定すると，LIDSシステム上で

プログラムがファイルに対してアクセスをする際

に，次のような順番でACLが参照されます（図3）．

①まず，プログラムを指定しない状態で，その行

為が許可されているかどうかACLを参照します．

行為が許可されている場合には，アクセスを許

可します．

② ①で行為が許可されていなかった場合には，改

めてプログラムを指定してあるACLを参照しま

す．そこで，行為が許可されている場合には，

アクセスを許可します．

③ ①②で行為が許可されていなかった場合には，

アクセスを拒否します．

●パーミッションの種類

これらのアクセス制御は，前項で述べたように

Linuxでのアクセス制御で許可されたものに対して

設定できます．

では，LIDSではファイルに対してどのようなパ

ーミッションを与えることが可能なのでしょうか．

LIDSを導入すると，ファイルやディレクトリに対

して表2の4種類のパーミッションが設定できます．



動作の拒否



No

プログラム

UNIXパーミッション -rwxr-xr-x root root

動作の拒否

No

Yes

Yes

LIDSでのパーミッション READONLY，DENY，…

LSM

●図2 LIDSを組み込んだシステムでのプログラムの権限チェック

動作の拒否


動作を許可するか？ ①


Yes

プログラム

デフォルトのACL プログラムを指定せずに

検査する

動作が許可される Yes

No

No

プログラムに対する ACLを検査する

②

③

●図3 LIDSを組み込んだシステムでのACLチェックの流れ

●LIDS設定の構文

LIDSでこれらのパーミッションを設定するに

は，lidsconfコマンドを使用します（図4）．

「どの“プログラム”が，どの“ディレクトリ／

ファイル”に対して，どのような“パーミッショ

ン”を持っているか」という書き方で，非常に直

感的なものになっています．

また，“プログラム”を省略した際には，デフォ

ルトのファイルACLとなります．つまり，すべて

のプログラムは，その“ディレクトリ／ファイル”

に対して，“パーミッション”に従う」という意味

になります．この記述方法は iptablesの書式（図5）

に似ているので，覚えやすいでしょう．

●パーミッションはサブディレクトリにも反映

また，LIDSでは，親ディレクトリに対してパー

ミッションを設定すると，サブディレクトリにも

そのパーミッションが継承されていきます．その

ため，「親ディレクトリ以下をREADONLYにして

おいて，特定のサブディレクトリをDENYにする」

といった設定方法が可能になっています．

●ファイルACLの例

例として，図6のような，ファイルやディレクト

リに対してのアクセス制御を行うファイルACLを

設定します．

① /以下のディレクトリは，すべてREADONLYと

しておきます．

② /etc/sshディレクトリは，sshの設定ファイルが

入っています．どのプログラムからのアクセスも

許可しないほうが良いので，DENYにします．

③ /var/log/messagesは，各種のログを書き加えて

いく必要があります．しかし，WRITEパーミッ

ションを与えてしまうと消去や改ざんも可能に

なってしまうため，追記（APPEND）のみを可

能にします．

これらのACLを設定するためには，次のコマン

ドを入力するだけで設定が可能になります．

①lidsconf -A -o / -j READONLY

②lidsconf -A -o /etc/ssh -j DENY

③lidsconf -A -o /var/log/messages -j

APPEND （実際は1行）

しかし，sshdを起動する際には設定ファイルを

読み込む必要があります．そのため，sshdに対し

てのみ，/etc/sshdディレクトリ以下を読み込み可

Oct. 2004 - 71


DENY 拒否．ディレクトリ名やファイル名は表示されるが，内部にアクセスすることはできない

READONLY 読み込みのみ．READはできるが，改変などはできない

APPEND 追記のみ．READと追記のみはできるが，改変や消去はできない

WRITE 読み込み／書き込み／消去などがすべてできる

●表2 LIDSで設定できるパーミッション

lidsconf -A ステート -s プログラム -o ディレクトリ／ファイル -j パーミッション

●図4 lidsconfコマンドの書式

※ステートに関しては後述の「②ステートフルACL」の項で解説します．

iptables -A INPUT -s 送信元 -d 宛先 -j 行為

●図5 iptablesの書式

etc　READONLY

ssh　DENY

sshd_config　DENY

/　READONLY

var　READONLY

log　READONLY

messages　APPEND

①

②

③

●図6 今回設定するアクセス制御

能（READONLY）に設定します．

lidsconf -A -s /usr/sbin/sshd -o

/etc/sshd -j READONLY （実際は1行）

と設定します．

●通常のLinux

次に，特権の分割について説明します．通常の

Linux上では，プロセスは

①ユーザモードで動作する

②特権で動作する

の2種類しかありませんでした．

たとえば図7のように，あるプログラムに1024

番以下のポートを使用させたい場合には特権を与

える必要がありますが，それにより不必要な権限

まで与えてしまうという弊害がありました．これ

は，そのプログラムに脆弱性が発見された場合に，

それらの権限を得られてしまう可能性があること

を意味します．

●Linuxケーパビリティ

そのため，カーネル2.4系列からLinuxケーパビ

リティというものが実装されています．これは，

今までの特権を29種類のLinuxケーパビリティ（表

3）に分割し，プログラムには，それぞれ必要なも

のだけしか与えないようにしようという考えです．

Linuxケーパビリティを用いて，プロセスに特権を

与えた際に，その特権の「内容」を調整することが

できます．説明が必要と思われるLinuxケーパビリテ

ィを表4に掲載していますので，参照してください．

●ケーパビリティバウンディングセット

あるプログラムが，特権を与えられた際にどの

ようなケーパビリティを持っているかは，ケーパ

ビリティバウンディングセットと呼ばれる「どの

ケーパビリティが許可されているかを示す表」に

よって決定されます．

Linuxケーパビリティを使用する場合には，通常

このケーパビリティバウンディングセットを修正し

て，通常のプログラムが特権で起動された際のデフ

ォルトケーパビリティを定義しておきます．そして

その起動したプログラムからケーパビリティを剥ぎ

取っていくという方式で，プログラムのケーパビリ

ティを調整していきます．プログラムに対してケー

パビリティの追加することはできません．

これに対し，LIDSではプログラムに対して個別

にケーパビリティを追加していく方式を採ります．

そのため，ケーパビリティバウンディングセット

で許可されるケーパビリティを極力少なくしてお

き，各プログラムが特権で起動されそうになる際

にケーパビリティを追加していくことになります．

●LIDSでの追加ケーパビリティ

LIDSでは，さらに次の2種類のケーパビリティ

が追加されています．

①CAP_PROTECTED

これをプログラムに与えると，起動されたプロ

グラムをkillコマンドなどを使って停止することが

できなくなります．これにより，侵入されても止

められたくないプロセス，たとえば syslogdや

snortdなどを停止不可能にします．

②CAP_KILL_PROTECTED

これをプログラムに与えると，ケーパビリティ

CAP_PROTECTEDを与えたプログラムをkillする


プログラムプログラム

1024番以下のポートを使いたい

特権で動作させる

弊害：不必要な特権の付与 GID／UID変更権ネットワーク設定変更権 …

●図7 通常のLinuxでは不必要な特権まで与えてしまう

②特権の分割

Linuxの場合

LIDSの場合

ことができます．たとえば，これを/etc/init.d/

syslogdに与えることにより，システムシャットダ

ウン時にCAP_PROTECTEDを与えたsyslogdを停

止させることができます．

◆◆◆

これらのケーパビリティを，必要に応じて各プ

ログラムに与えることにより，システムをより強

力に保護することが可能になります．

●LIDSでケーパビリティを設定する構文

LIDSでこれらのケーパビリティを操作するには，

ファイルACLのときと同じく lidsconfコマンドを使

用します（図8）．「ある特定の“プログラム”に対

して，ある“ケーパビリティ”（“オプション”）を

付与する」という書き方で，こちらも非常に直感

的なものになっています．

このようにして，プログラムと対応する権限

（ケーパビリティ）を記述していったリストを「権

限ACL」と呼びます．

●ケーパビリティ付与の例

例として，先ほどと同じ sshdを用いましょう．

sshdは，ポート番号22を使用します．そのため，

sshdに対して1024番以下のポートを使用できるケ

ーパビリティを与えま

す．

さらに，セキュリテ

ィ上，付与するものは

最小限にしたいので，

ポート番号 22のみの

使用権を与えます（リ

スト1）．

これにより，sshd

はポート番号 22を使

用することが可能にな

ります．

Oct. 2004 - 73


lidsconf -A ステート -s プログラム -o ケーパビリティ（オプション） -j GRANT

●図8 LIDSでケーパビリティを設定するためのlidsconfコマンドの構文

※オプションは省略する場合もあります．

CAP_CHOWN CAP_MKNOD CAP_SYS_CHROOT

CAP_DAC_OVERRIDE CAP_NET_ADMIN CAP_SYS_MODULE

CAP_DAC_READ_SEARCH CAP_NET_BIND_SERVICE CAP_SYS_NICE

CAP_FOWNER CAP_NET_BROADCAST CAP_SYS_PACCT

CAP_FSETID CAP_NET_RAW CAP_SYS_PTRACE

CAP_IPC_LOCK CAP_SETGID CAP_SYS_RAWIO

CAP_IPC_OWNER CAP_SETPCAP CAP_SYS_RESOURCE

CAP_KILL CAP_SETUID CAP_SYS_TIME

CAP_LEASE CAP_SYS_ADMIN CAP_SYS_TTY_CONFIG

CAP_LINUX_IMMUTABLE CAP_SYS_BOOT

●表3 Linuxケーパビリティ一覧

CAP_CHOWN ファイルのUIDとGIDを任意に変更することを許可する

CAP_DAC_OVERRIDE ファイルの読み込み／書き込みと実行権限のチェックをバイパスする

CAP_KILL シグナル送信に対する権限チェックをバイパスする

CAP_NET_ADMIN さまざまなネットワークに関係する操作（インターフェースの設定や，ルーティング

テーブルを変更するなど）を許可する

CAP_NET_BIND_SERVICE インターネットドメインで予約されているソケットポート番号（1024番以下のポート）

へのバインディングを許可する

CAP_SYS_TIME システムクロックの変更を許可する

●表4 一部のLinuxケーパビリティの説明

lidsconf -A -s /usr/sbin/sshd -o CAP_NET_BIND_SERVICE 22 -j GRANT

●リスト1 sshdにポート番号22を使用する権限を与える

LIDSでは，プログラムに対してパーミッションや

ケーパビリティを与えたときに，そのプログラムが

プロセスとして起動したときの子プロセスに対し

て，以下の条件でパーミッションやケーパビリティ

が継承されていきます．

①親プロセスと子プロセスが同じプログラムの場

合には，親プロセスのパーミッションやケーパ

ビリティを無条件で継承する

②親プロセスと子プロセスが異なるプログラムの

場合には，その子プロセスにパーミッションや

ケーパビリティを継承させても良いかどうか設

定できる

Apacheでの継承を例に説明します．

①httpdに対してパーミッションやケーパビリティ

を与えた場合には，接続クライアントが増えて

子プロセスが起動した際に，親と同じプログラ

ムのため，パーミッションやケーパビリティを

無条件で引き継ぐ

②apachectlに対してパーミッションやケーパビリ

ティを与えた場合には，子（httpd）は親と異な

るプログラムのため，継承させるかどうかを設

定することができる

また，継承には子プロセスまでの継承や，孫プ

ロセスまでの継承など，どの段階まで継承させる

かを設定することができます．もちろん，無制限

に継承させることも可能です．

●継承レベルの設定方法

継承レベルを設定するには，lidsconfコマンドで

ACLを設定する際に，リスト2のように，-iオプシ

ョンを用いて設定します．上の例ですと，継承レ

ベルが2ですので，孫プロセスにまでパーミッショ

ンやケーパビリティを継承させることができます．

継承レベルを無制限に設定するには，“-1”を指定

します．

LIDSで，プログラムがACLに記述されたアクセ

ス制御を違反した際のログ注3は，リスト3のような

ものになります．これは，DENYに設定してある

/etc/sshdディレクトリに対して，

# ls /etc/sshd

とした際のログです．「lsプログラムがsshdを読も

うとした」と，拒否された行為のログが出力され

ます．

LIDSでは，プログラムがACL違反を行った際に

しか，ログやコンソールに出力を行わず，どの行

為が何時に許可されたかを残しておく監査ログの

ような機能はありません．監査機能があると非常

に便利だということは開発者たちも認めています

ので，今後，監査機能を付け加えてくれるだろう

と期待しています．

LIDSでのACLやケーパビリティなどについて


# lidsconf -A -s /usr/local/apache/bin/apachectl -o /var/www -i 2 -j READONLY

●リスト2 孫プロセスまでパーミッションやケーパビリティを継承

注3）Debian GNU/Linuxの場合には/var/log/kern.log，Fedora Coreの場合には，/var/log/messagesです．

Jul 24 21:28:13 localhost kernel: LIDS: ls (dev 3:1 inode 597994) pid 1564 ppid 1199 uid/gid (0/0) on(tty1) : attempt to open sshd for reading

●リスト3 アクセス違反時のログ

パーミッション／ケーパビリティの継承

Apacheでの継承の例

LIDSのログの見方

LIDSの設定ファイル

LIDSの設定ファイルの格納場所

は，/etc/lidsディレクトリ内に格納されています．

/etc/lidsディレクトリ自身は，LIDSでアクセスが

DENYになっているため，保護されている形にな

ります．

/etc/lidsディレクトリ内に，全部で13個の設定

ファイルが入っています（表5）．

このディレクトリ内のファイルは lidsconfコマン

ドで作成されるので，手で編集しないほうが無難

です．

LIDS内部でACLをどのように判断しているか理

解するため，lids.confを見てみましょう（リスト4）．

lids.confを見てみると，制限したいディレクトリ

やプログラムの横に数字が並んでいます．これは，

図9のような書式になっています．

● inode

たとえば，/ディレクトリに関しては，リスト4

①のようになっていますが，これはプログラムを

指定していないデフォルトACLのため，「inode番

号2，デバイス番号769の/に対して，パーミッシ

ョン1を与えている」となります．

また，/usr/sbin/sshdが/etc/sshにREADONLY

のパーミッションを設定されている箇所は，リス

ト4②となっており，「inode番号565817，デバイス

番号769のプログラム/usr/sbin/sshdが，inode番

号662820，デバイス番号769の/etc/sshに対して，

パーミッション1を与えられている」という意味に

なります．

●デバイス番号

デバイス番号は，メジャー番号とマイナー番号

の組み合わせになっています．デバイス番号769に

ついては，

Oct. 2004 - 75


lids.ini ACL DISCOVERYをON／OFFするファイル

lids.pw ステート変更時や設定変更時に使用するパスワードファイル

lids.conf システムでのデフォルトのACLとケーパビリティ

lids.cap プログラムへのデフォルトケーパビリティ

lids.boot.conf BOOTステートのACLとケーパビリティ

lids.boot.cap BOOTステートのデフォルトケーパビリティ

lids.boot.acl カーネルが読み込める形にコンパイルされた，BOOTステートのACLとケーパビリティのセット

lids.postboot.conf POSTBOOTステートのACLとケーパビリティ

lids.postboot.cap POSTBOOTステートのデフォルトケーパビリティ

lids.postboot.acl カーネルが読み込める形にコンパイルされた，POSTBOOTステートのACLとケーパビリティのセット

lids.shutdown.conf SHUTDOWNステートのACLとケーパビリティ

lids.shutdown.cap SHUTDOWNステートのデフォルトケーパビリティ

lids.shutdown.acl カーネルが読み込める形にコンパイルされた，SHUTDOWNステートのACLとケーパビリティのセット

●表5 /etc/lidsディレクトリ内部に格納されているファイル

## This file is auto generated by lidsconf# Please do not modify this file by hand#0:0::1:0:2:769:/:0-00:0::0:0:130360:769:/etc/lids:0-00:0::3:0:888801:769:/var/log:0-00:0::0:0:662820:769:/etc/ssh:0-0565817:769:/usr/sbin/sshd:1:0:662820:769:/etc/ssh:0-0

●リスト4 lids.confの内容

①

②

lids.confファイルの見方

プログラムのinode:デバイス番号:プログラム:パーミッション:継承レベル:ディレクトリ／ファイルのinode:デバイス番号:時間（Obsolete）

●図9 lids.confの書式

769 = 00000011 00000001

ですから，上記は「メジャー番号＝3，マイナー番

号＝1」の意味です．筆者のPCでは，図10のように

出力されるので，これは/dev/hda1を表しています．

● inodeが変更されたときの解決方法

このように，LIDSではACLを inodeとデバイス

番号で管理しています．そのため，apt-getやyum

updateなどでプログラムの inode番号が変更された

場合には，ACLがうまく動作しなくなります．

これを解決するためには，パッケージをアップ

デートした後に，その都度コマンド

# lidsconf -C

を実行して，LIDS設定ファイル内での inodeリス

トを更新する必要があります．

LIDSを導入するには，カーネルに当てるパッチ

と lidstoolsと呼ばれるLIDSを設定するためのツー

ル類が必要になります．これらは別々に導入する

こともできますが，LIDSのリリース版にはその時

点での最新の lidstoolsが同梱されていますので，そ

ちらを使ったほうが無難でしょう注4．

また，LIDSのパッチは素の（ftp.kernel.orgから

ダウンロードした）カーネルソースに対応した形

になっていますので，Red Hat版やDebian版のカ

ーネルに導入することは困難です．有志ユーザが

個別に対応版を出していますが，現時点でのLIDS

は素のカーネルにのみ対応していると考えたほう

が良いでしょう．

LIDSのリリース版はhttp://www.lids.org/か

らダウンロードできます．現在の最新バージョン

（rc版ですが）は，カーネル 2.6 .7用が「 l ids -

2.2.0rc3-2.6.7.tar.gz」，カーネル2.4.27用が「lids-

1.2.2rc2-2.4.27.tar.gz」になります．

ダウンロードしたファイルを展開すると，カーネ

ル2.6.7用の場合は「lids-2.2.0rc3-2.6.7.patch」という

カーネルに当てるパッチと，「lidstools-2.2.5rc1.tar.gz」

という lidstoolsパッケージがあります．

LIDSを導入するには，

①カーネルに対してパッチを当てる

②パッチを当てると，「Security Options」にLIDS

の項目が増えるので，選択する注5

③オプションを選択したら，カーネルをmakeする

④makeが終わったら，lidstools-2.2.5rc1.tar.gzを展

開してインストールする

という手順を踏みます．

ただし，lidstoolsでシステムが稼動するための必

要なACLを作成していない場合には，このまま再

起動してしまうとシステムが立ち上がらなくなって

しまいます．そのため，最後の再起動を行う前に，

⑤ / e t c / l i d s / l i d s . i n i ファイルで，「ACL _

DISCOVERY=1」とする注6

⑥「lidsconf -C」コマンドを使用して，ACLを再作

成する

としてから再起動を行います．

システム起動時に LIDSを無効にするには，


注4）LIDSのリリース版と異なるlidstoolsを使用した際に，まれにパラメータが表示されないなどの不具合があります．

注5）この際，カーネル組み込みか，モジュールにするかの選択ができます．

注6）のちほど，本文の「③ACL DISCOVERY機能」の項で解説します．

brw-rw---- 1 root disk 3, 1 May 6 1998 /dev/hda1

●図10 メジャー番号，マイナー番号とデバイスの関係

LIDSの導入方法

カーネルパッチとlidstools

ダウンロード

導入手順

LIDSを無効にするには

GRUBや LILOなどで「/boot/vmlinuz-2.6 .7

root=/dev/hda1 ro lids=0」と“lids=0”を指定しま

す．このオプションで起動した際には，LIDSが組

み込まれていない状態と同じように起動します．

LIDS-2系列から，カーネル2.6に対応したため，

以下の点が新機能として盛り込まれました．

①LSMのサポート

②ステートフルACL

③ACL DISCOVERY機能

それぞれを簡単に見ていきましょう．

すでに本特集でも述べられていますが，カーネ

ル2.6から，Linuxにさまざまなセキュリティモデ

ルをモジュールとして組み込むことができるよう

になりました．これを可能にしているのが，LSM

という共通のフレームワークです．LIDSはLIDS-2

系列から，LSMに対応しました．

ただし，LSMに対応したため，

¡ディレクトリ／ファイルを完全に隠すことができ

なくなったため，隠しファイルではなく動作拒否

のファイルしか作成できなくなってしまった

¡iptablesと連動するIP_NFMARK機能がなくなっ

たため，ACL違反のプログラムが生成したパケ

ットは送信しないなどの「ワーム拡散防止機能」

が使えなくなった

など，機能面で若干の縮小がありました．

LIDSでのACLは，旧バージョンでは1種類しか

なかったため，たとえば/etcと/var以下のファイ

ルをREADONLYにしてしまうと，

¡起動時に/etc/mtabが変更されないため，mount

に手を加えなくてはならない

¡シャットダウンしてプロセスを停止するときに，

/var/runのプロセスIDファイルが削除できない

などの弊害がありました．

これを解決するために，LIDS-2系列からはシス

テムを表6の3つの状態（ステート）に分けて，そ

れぞれのステートでACLを記述することが可能に

なっています．

このため，さきほどの問題は，表7のようにして

解決できるようになりました．

このように，ステートフルACLの採用により，

柔軟なACLの作成が可能になっています．

●従来のACL作成方法

LIDSなどのセキュアOSでは，ACLを記述する

際には非常に多くのプログラムの動作を把握する

必要があります．

以前のバージョンでは，特定のACLでプログラ

ムが動作しなかった場合には，/var/log/messages

Oct. 2004 - 77


BOOT システム起動時からカーネル封印まで

POSTBOOT カーネル封印後．通常はこのステートで運用を行う

SHUTDOWN このステートに移行してから，システムをシャットダウンする

●表6 ステートの種類

BOOT時 /etc以下と/var以下はREADONLYにし，/etc/mtabをWRITEにする

POSTBOOT時 /etc以下と/var以下はすべてREADONLYにする

SHUTDOWN時 /var以下はREADONLYだが，/var/runをWRITEにする

●表7 ステートフルACLによる解決法

最新版LIDSに盛り込まれた機能

①LSMのサポート

②ステートフルACL

③ACL DISCOVERY機能

を見て，どのACL違反によりプログラムが動作し

なかったのかを確認してACLを調整する必要があ

りました．そのため，すべてのプログラムに対し

て調査と再起動を繰り返さなければならず，ACL

の作成が煩雑なものになってしまっていました．

●ACL DISCOVERYを使用する

そこで，LIDS-2系列からはACL DISCOVERY機能

が盛り込まれました．これは，一種のデバッグモー

ドで，プログラムのACL違反をログに残しつつ，シ

ステムはプログラムのACL違反を無視して動作を続

けるというもので，SELinuxにおけるpermissiveモ

ードと同様の機能です．これにより，あるプログラ

ムを動作させるにはどのACLを追加すれば良いのか

を，簡単に判断できるようになりました．

たとえば，ACL DISCOVERYモードをONにして

おくと，ログファイルにリスト5のように記録され

ます．これは，proftpdが動作するために，このACL

を追加してあげれば良いという意味になります注7．

●PerlスクリプトによりACLを自動生成

また，LIDSパッケージに同梱されているPerlス

クリプトにより，ACL違反のログからその動作を

許可するために必要なACLを作成することが可能

になりました．SELinuxにおけるaudit2allowコマン

ドに似ています．

「lidstools-2.2.5rc1/doc/acl_discovery/lids_acl_

discovery.pl」を使用し，“lidsconf -S”コマンドと併

用することにより，/var/log/messages上の前述の

ようなログから，各ステートのconfファイルとそ

の設定スクリプトを（一部できないことはありま

すが）自動生成してくれます．

LIDSの情報源を表8にまとめました．海外では

やはり①本家のメーリングリストと②フォーラム

で，活発に議論が行われています．

日本のサイトでは，③LIDS-FAQの和訳が「Linux

JF (Japanese FAQ) Project.」から見ることができま

す．このLIDSはかなり古いバージョンのものです

ので，直接使用することは難しいですが，LIDSに

対する基本的な考えがよくまとまっています．

また，④筆者のWebサイトにも，最新の情報を

掲載しています．

以上で述べたように，LIDSはSELinuxと比べて

セキュリティの高さに関しては劣りますが（もち

ろん，通常のLinuxよりは上です），設定の方法が

直感的でわかりやすくなっています．そのため，

セキュアOSとは何かを勉強したいという人には，

入門用途としてぴったりではないかと思われます．

これからセキュアOSを使おうとしている方は，

ぜひLIDSを使ってみてください．s


Jul 24 18:16:10 localhost kernel: LIDS_ACL_DISCOVERY:[state 1]565738:3145729:proftpd:7:0:905223:3145729:proftpd.scoreboard:0-0

●リスト5 ACL DISCOVERYモードでログファイルに出力される内容

注7）ただし，フルパスでプログラムやディレクトリを表示する機能がないため，それは適宜調べる必要があります．

■海外のWebサイト

① LIDS Project（本家） http://www.lids.org/

② LIDS Forum http://forum.lids.org/

■日本のWebサイト

③ LIDS-FAQ（旧版） http://www.linux.or.jp/JF/JFdocs/LIDS-FAQ/

④ 筆者のWebサイト http://www.honto.info/LIDS/

●表8 LIDSの情報源

LIDSの情報源

まとめ

Oct. 2004 - 79

jailはFreeBSDで提供される，プロセスとその子

孫を閉じ込めることのできる機能です注 1．

FreeBSD 4.0-RELEASEのときに，目玉機能として

実装されました．

同じような働きをする機能にchrootがあります

が，jailはこれを拡張したものであると考えるこ

とができます．実現できることは以下のようなこ

とです．

①jail環境ごとにchrootできる

②jail環境ごとにIPアドレスが利用できる

③jail環境ごとにdevfsが制限付きで利用可能

④制限されたプロセス空間を利用できる

そして，これらの機能を，1つのホスト上で同時

に複数利用することができます．

いろいろと書くよりも，百聞は一見にしかずと

いうことで，動作を見ていくことにしましょう．

サンプル環境として，今回は FreeBSD 5.2.1-

RELEASE-p9を用意しました．ここでは，2つの jail

が動作している環境を例に見ていくことにします．

まず，jailに関連した管理コマンドには「jls」

「jail」「jexec」などがあります．

動作している jailを確認する場合には，jlsコマン

ドを使用します（図1）．jlsコマンドにより，それ

ぞれの jail環境での

①jailのIDであるJID

②IPアドレス

③ホストネーム

④jailの置かれているパス

この章では，SELinuxと対比する意味で，FreeBSDで提供されるjail というセキュリティ機能を紹介します．非常に柔軟性が高く，セキュアOSのように利用することもできますので，ぜひ参考にしてください．

籠谷和男 KOMORIYA Kazuo ●[email protected]


注1）jailは「牢獄」という意味ですので，まさしくこのイメージです．

% jlsJID IP Address Hostname Path2 172.16.120.26 jail-large2.komoriya.ddo.jp /home/jail-large21 172.16.120.25 jail-large1.komoriya.ddo.jp /home/jail-large1

●図1 jlsコマンド実行結果

① ② ③ ④

jailとは jailの動作の様子

稼働中のjailの確認

を確認することができます．

次に，ホスト環境とそれぞれの jailのインターフ

ェースを確認してみることにしましょう．jailのな

かでコマンドを実行する場合には，jexecコマンド

を使用します．書式は，

jexec JID command …

となります．

ここでのcommandは，もちろん JIDで指定した

jailの中で実行されるため，その jailの中で実行がで

きることが前提となります注2．

図2を見てください．このように，jailに付与し

た IPアドレスだけが，それぞれの jailで利用できる

ネットワークインターフェースとなります．

次は，ホスト環境と，それぞれの jailにおけるポ

ートのLISTEN状態を確認してみることにしましょ

う（図3）．

ホスト環境では，ここで動作しているすべての

インターフェースの状態が確認できますが，それ

ぞれの jailでは，その jailに関係するものだけが見

えていることがわかると思います．

次は，ホスト環境とそれぞれの jailのプロセス状


注2）ホスト環境にしかないコマンドは，ホスト環境でしか実行できません．

% ifconfig -afwe0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500

ether 02:06:1b:01:fa:20ch 1 dma -1

fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500inet 172.16.120.23 netmask 0xfffffe00 broadcast 172.16.121.255

inet6 fe80::2d0:59ff:feb5:c200%fxp0 prefixlen 64 scopeid 0x2 inet 172.16.120.25 netmask 0xffffffff broadcast 172.16.120.25

inet 172.16.120.26 netmask 0xffffffff broadcast 172.16.120.26

ether 00:d0:59:b5:c2:00media: Ethernet autoselect (10baseT/UTP)status: active

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3

% sudo jexec 1 ifconfig -afwe0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500

ether 02:06:1b:01:fa:20ch 1 dma -1

fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500inet 172.16.120.25 netmask 0xffffffff broadcast 172.16.120.25

ether 00:d0:59:b5:c2:00

media: Ethernet autoselect (10baseT/UTP)status: active

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384% sudo jexec 2 ifconfig -afwe0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500

ether 02:06:1b:01:fa:20ch 1 dma -1

fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500inet 172.16.120.26 netmask 0xffffffff broadcast 172.16.120.26

ether 00:d0:59:b5:c2:00

media: Ethernet autoselect (10baseT/UTP)status: active

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384

●図2 ホスト環境とjail環境でのネットワークインターフェースの確認

←ホスト環境でのインターフェースの確認

↑ホスト環境で実インターフェースが使用するIPアドレス

↑jail環境（jail-large1）で使用するIPアドレス

↑jail環境（jail-large2）で使用するIPアドレス

←JID=1のjail（jail-large1）でのインターフェースの確認

↑jailの中では，jail環境（jail-large1）で使用するIPアドレスだけが設定されているように認識される

↑MACアドレスは，実ホストのものと同様となる

←JID=2のjail（jail-large2）でのインターフェースの確認

↑jailの中では，jail環境（jail-large2）で使用するIPアドレスだけが設定されているように認識される

↑MACアドレスは，実ホストのものと同様となる

jailでのネットワークインターフェースを確認

jailでのネットワークサービス

制限されたプロセス空間

態を確認してみることにしましょう（図4）．

ほかの状態同様，ホスト環境ではすべてのプロ

セスが見えますが，それぞれの jailでは，その jail

に関係するものだけが見えていることがわかると

思います．

procfsでも，それぞれのプロセスがどの環境で動

作しているかが確認できます．その際，

「/proc/[pid]/status」の最後のフィールドで，どの

環境で動作しているかを見ることができるように

なっています（図4の※を参照）．

ここまで紹介してきた例は，基本的にフルセッ

トのOS環境を jailで構築したものでした．しかし，

jailの利用用途は，この限りではありません．

今回の例のようにフルセットのOS環境を，1つ

のハードウェア上で複数構築することもできます

し，DNSサーバしか動作しない jail，SMTPゲート

ウェイしか存在しない jailなど，さまざまな用途を

限定した jailを構築することも可能です．

こういった，制限の厳しい jail環境を構築してい

くことで，jailをある意味でのセキュアOSとして

利用することができると言えるかもしれません．

FreeBSDには，TrustedBSDの成果もマージされ

ている（いわゆるMACの実装です）ので，jailと

これらの機能を組み合わせていくことで，より堅

牢な環境を構築することができるのではないかと

思います．s

Oct. 2004 - 81

App.3◆FreeBSDのセキュリティ機能～jailの紹介

% netstat -an|grep LISTENtcp4 0 0 *.49167 *.* LISTENtcp4 0 0 *.6000 *.* LISTENtcp4 0 0 172.16.120.23.80 *.* LISTENtcp4 0 0 172.16.120.26.25 *.* LISTENtcp4 0 0 172.16.120.25.25 *.* LISTENtcp4 0 0 172.16.120.25.22 *.* LISTENtcp4 0 0 172.16.120.23.22 *.* LISTEN% sudo jexec 1 netstat -an|grep LISTENnetstat: kvm not availablenetstat: kvm not availabletcp4 0 0 172.16.120.25.25 *.* LISTENtcp4 0 0 172.16.120.25.22 *.* LISTEN% sudo jexec 2 netstat -an | grep LISTENnetstat: kvm not availablenetstat: kvm not availabletcp4 0 0 172.16.120.26.25 *.* LISTEN

●図3 それぞれの環境におけるLISTEN状態の確認

←ホスト環境でのLISTEN状態の確認

←JID=1のjail環境でのLISTEN状態の確認

←JID=2のjail環境でのLISTEN状態の確認

% ps -ax|wc80 476 3587

% sudo jexec 1 ps -axPID TT STAT TIME COMMAND711 ?? SsJ 0:00.41 /usr/sbin/syslogd -s

854 ?? IsJ 0:00.51 /usr/sbin/sshd861 ?? SsJ 0:03.55 sendmail: accepting connections (sendmail)867 ?? IsJ 0:00.11 sendmail: Queue runner@00:30:00 for /var/spool/client882 ?? SsJ 0:00.75 /usr/sbin/cron

17746 p0 R+J 0:00.02 ps -ax% sudo jexec 2 ps -axPID TT STAT TIME COMMAND1101 ?? SsJ 0:00.41 /usr/sbin/syslogd -s

1251 ?? SsJ 0:03.46 sendmail: accepting connections (sendmail)1257 ?? IsJ 0:00.11 sendmail: Queue runner@00:30:00 for /var/spool/client1272 ?? IsJ 0:00.77 /usr/sbin/cron17747 p0 R+J 0:00.03 ps -ax% cat /proc/1101/statussyslogd 1101 1 1101 1101 -1,-1 sldr 1089613231,193913 0,93734 0,340851 select 0 0 0,0 jail-large2.komoriya.ddo.jp

●図4 プロセス状態の確認

←ホスト環境では，jail環境のプロセスも含めすべてが見える

←JID=1のjail環境のプロセス確認

↑このSTAT項目の「J」は，jail内のプロセスであることを示すフラグ

↑こちらにも「J」があるが，こちらはJID=2のもの

←pid=1101のプロセスの詳細確認（ホスト環境で確認）

←※

jailの利用用途

FreeBSDでのセキュアな環境の構築

all about selinux

Documents