TOMOYO Linux 1.1 が公開されました。（続）

ようやくアナウンスできました。＼（＾ｏ＾）／

http://sourceforge.jp/projects/tomoyo/ からもダウンロードできるようになりました。
リリースファイルに隠し属性が割り当てられている場合、「プロジェクトページ」にはダウンロード用アドレスが表示されないようになっていますが、実際には「http://prdownloads.sourceforge.jp/プロジェクト名/」を開けば、隠し属性が割り当てられたリリースファイルであってもダウンロードできてしまいます。つまり、ダウンロード用アドレスを隠す術は無いのです。（笑）

version 1.1 を公開後、 CentOS 4.3 と SuSE (OSS) 10.1 beta 9 への対応も始めました。

CentOS 4.3 は Fedora Core と同じ操作性でした。まぁ、 RedHat Enterprise Linux をベースにしているから当然なのでしょう。
なお、 RedHat Enterprise Linux 4 および CentOS 4.3 用の 2.6.9-34.EL カーネルでは CVE-2005-2973 の修正がまだ行われていませんでした。

SuSE (OSS) 10.1 beta 9 で TOMOYO Linux を動かしてみたのですが、 RedHat 系でも Debian 系でも見たことの無い特異な振る舞いをしていました。
なんと、名前なしパイプ（「ls -l /proc/*/fd/」したときに「pipe:[数字]」と表示されるものです）に対して（おそらく /proc/pid/fd/ ディレクトリ経由で） open() しているのです。（＾＾；
正直、「名前なしパイプ」にパス名を使ってアクセスできるとは思っていませんでした。
version 1.1 は名前なしパイプを扱えないので、 SuSE で TOMOYO Linux を動かすことはできません。名前なしパイプを扱えるようにするための修正は既に済んでおり、次回リリースに含まれる予定です。

TOMOYO Linux 1.1 が公開されました。

今日は木之本桜ちゃんとサクラ姫の誕生日ですから。（笑）

でも、ダウンロード用アドレスはまだお知らせできません。見つけた場合でも、アナウンスがあるまでは黙っていてください。あぁ、１ヶ月以上も前から創ってあったのに、誕生日までにプレゼントが届かなかっただなんて、一生の不覚ですわ。（涙）

version 1.1 では、ファイルの書き込み権限の細分化が行われました。既に http://kumaneko-sakura.sblo.jp/article/463433.html で紹介したとおりです。システムの振る舞いを解析するためのツールとしても威力を発揮すると思います。
また、 /proc/self/ ディレクトリの特例も含めました。これは、 http://kumaneko-sakura.sblo.jp/article/506616.html で紹介しました。
例外用ポリシーの更新とドメイン用ポリシーの再取得が必要になりますが、今までの知識が無駄になることはありません。

ツールの面では大きな変更はありませんが、とりあえず http://kumaneko-sakura.sblo.jp/article/501981.html で紹介したツールを含めました。ファイル名は ld-watch.c です。ただし、まだ手順が確立されていないので、インストール手順書では触れていません。

また、試験的にバニラカーネル用以外のパッチも含めました。バニラカーネル用と合わせて２１種類にもなってしまいました。動作テストのために VMware 環境をたくさん用意する必要があり、ＨＤＤ容量が不足して大変でした。（自爆）

CVE-2005-2973 は SAKURA に含まれる機能の１つである「ローカルポートの自動割当機能の制限」を行うためにフックを掛けるべき場所を探していて発見したものです。この脆弱性は、たった２４行のＣ言語のプログラムでローカルユーザが Linux システムをサービス不能に陥らせることができます。メモリ不足などで強制終了させられない限り、１００％成功します。また、80386用のマシン語プログラム（ 0x00 0x0A 0x0D を含まないように工夫した状態）でも１３６バイトで実現できました。リモートからでも適当なバッファオーバーフローを発見すれば流し込むことも可能だと思います。
最近公開された RedHat Linux 9 用の 2.4.20-46.9_legacy 、 Debian Sarge 用の 2.4.27-10sarge2 および 2.6.8-16sarge2 カーネルでも修正されています。 IPv6 を有効にしている Linux ユーザはアップデートすることをお勧めします。
ディストリビュータ用のカーネルでも修正されてきたようなので、今後、バニラカーネル用の TOMOYO Linux パッチをベースにディストリビュータ用の TOMOYO Linux パッチを作成する場合、 net/ipv6/udp.c の部分で衝突が発生するので注意してください。

それから、 kernel/sysctl.c の sysctl_string() が成功時に 0 ではなく 1 を返すようにするという修正はカーネル 2.6.15 で取り込まれましたが、ディストリビュータ側での対応はバラバラのようです。今後、バニラカーネル用の TOMOYO Linux パッチをベースにディストリビュータ用の TOMOYO Linux パッチを作成する場合、 sysctl_string() ではなく sysctl_intvec() のほうに適用されてしまわないように注意してください。

ちなみに、これがこのブログの１００個目の記事です。（祝）

今後の予定について

いろいろ Tips を書いてきましたが、いよいよネタ切れになりました。

今までは、デフォルトでインストールされるアプリケーションを対象に、全般的な内容について紹介してきました。先日、自宅の PC を Windows ME から Windows XP にアップグレードし、 VMware Player を動かすことができるようになりました。今後は、具体的なアプリケーション毎のポリシー策定手順などを VMware 上で確認して写真入りで紹介していこうと思います。ただし、アプリケーション毎の設定に関するノウハウや侵入テストツールの使い方などのノウハウを私は持っていませんし、実際に複数台用意してドメインを構成したりするほどの資源もありません。 TOMOYO Linux 以外の内容に関しては、他のサイトを探してください。
なお、今までよりも時間が必要になるので、毎日更新というのは無理です。

「この点についてもっと知りたい」「こういうことを実現したいんだけどどう設定すればいいのかな？」「こういうエラーが出るけれどどうして？」等、皆様からの質問やフィードバックを基に、今後の話を進めていきたいと思います。このページに書いてあることの一部は、各種ドキュメントや手順書の素材としても使われます。皆様からの質問やフィードバックをお待ちしています。

ccs-auditd が取得するログについて

ccs-auditd が取得するログは、そのままドメイン用ポリシーとして追加できる形式になっています。

ccs-auditd はログを追記するだけで、ログのローテーションは行いません。 必要に応じて、以下のような内容のファイルを /etc/logrotate.d/tomoyo という名前で作成してください。
（この例は /var/log/tomoyo/ ディレクトリに reject_log.txt という名前で保存している場合です。 /var/log/tomoyo/* と指定してしまうと既にローテーションされたファイルも再度ローテーションされてしまうので注意してください。）

/var/log/tomoyo/*.txt {   weekly   rotate 9   missingok   notifempty   nocreate }

あるいは、定期的にログインして mv コマンドでファイル名を変更するようにしてください。

udev の扱いについて

/dev/ ディレクトリのデバイスファイルを管理する udev は、 /dev/ ディレクトリに udev のためのディレクトリを作成します。ただし、使われるディレクトリ名はバージョンによって異なっているようです。

もし、 /dev/.udevdb/ ディレクトリが存在している場合、以下のようなパターンを指定してください。

file_pattern /dev/.udevdb/\*

もし、 /dev/.udev/ ディレクトリが存在している場合、以下のようなパターンを指定してください。

file_pattern /dev/.udev/\* file_pattern /dev/.udev/\*/ file_pattern /dev/.udev/\*/\* file_pattern /dev/.udev/\*/\*/ file_pattern /dev/.udev/\*/\*/\* file_pattern /dev/.udev/\*/\*/\*/ file_pattern /dev/.udev/\*/\*/\*/\* file_pattern /dev/.udev/\*/\*/\*/\*/ file_pattern /dev/.udev/\*/\*/\*/\*/\*

今後の機能拡張について

カーネル 2.6.16 が公開されたのでそろそろ TOMOYO Linux パッチもバージョンアップしようと思います。

バージョンアップ後、次のような機能拡張ができないかとぼんやりと考えています。

現時点では、 file_pattern として以下のような指定をすることができます。

file_pattern /proc/\$/environ file_pattern /proc/\$/status file_pattern /proc/\$/cmdline file_pattern /proc/\$/stat file_pattern /proc/\$/statm file_pattern /proc/\$/cpu file_pattern /proc/\$/maps file_pattern /proc/\$/mem file_pattern /proc/\$/mounts

しかし、 file_pattern だと、指定した階層までしかパターン化できませんし、その階層に作られるファイル名を全て把握していなければいけません。そのため、 /proc/\$/ の部分だけをパターン化するという場合に

dir_pattern /proc/\$/

のような指定ができると便利かなぁと考えています。

実現できるかどうかはまだ判りません。完全一致の file_pattern はパス名を書き直す必要が無いので簡単なのですが、部分一致の dir_pattern はパス名を書き直す必要があるためメモリの割り当て・解放処理という面倒な問題が発生してしまいます。

/proc/self/ ディレクトリの特例について

Linux では、自プロセスに関する情報は「/proc/self/」ディレクトリから取得できるようになっています。そして、 /proc/self は実際には「自プロセスのプロセスＩＤの名前が付けられたディレクトリ」へのシンボリックリンクとして実現されています。そのため、自プロセスに関する情報は実際には「/proc/自プロセスのプロセスＩＤ/」ディレクトリから取得されます。

version 1.0.2 までは /proc/self/mounts 等の自プロセスの情報を参照するためのアクセス許可は、 /proc/self/mounts ではなく、 /proc/プロセスＩＤ/mounts （実際にはパターン化を行って /proc/\*/mounts）というパス名で与えていました。しかし、この方法でアクセスを許可すると、自プロセス以外に対する参照も認めてしまうことになります。カーネル 2.6 では /proc/self/ ディレクトリのファイルに対する書き込みを行う場合が発生しているようですので、自プロセス以外のディレクトリにはなるべく書き込み権限を与えないようにする必要がありそうです。

そこで、次のバージョンでは、パス名を導出する際に、「/proc/自プロセスのプロセスＩＤ/」ディレクトリを特例として「/proc/self/」ディレクトリにマッピングすることにしました。これは、「TOMOYO Linux のパス名の最後の / より前にシンボリックリンクが含まれることは無い」という規則に違反することになりますが、以下のようなメリットが生まれます。

• 自分以外のプロセスの情報にアクセスする必要が無ければアクセスを禁止することができる
• allow_read で自プロセスに関する情報の参照を許可することができる

オンラインアップデートを行う際の注意点

ここに書かれている内容は現時点における考え方です。絶対に安全確実であると断言できる方法ではなく、また、最善の方法であるとは限りません。

/sbin/init が使用するファイルがアップデートされた場合、 /sbin/init をリロードするために /sbin/init から /sbin/init が起動されるので、 /sbin/init が実行されるドメインに対して /sbin/init の実行許可を与えてください。具体的には、以下のようなアクセス許可をドメイン用ポリシーファイルに追加してください。

<kernel> /sbin/init 1 /sbin/init

「<kernel> /sbin/init」から /sbin/init が実行されると「<kernel> /sbin/init /sbin/init」というドメインに遷移してしまうので、それを避けるために /sbin/init を initializer として指定してください。以下のような指定を例外ポリシーファイルに指定することで、 /sbin/init がリロードされた場合でも「<kernel> /sbin/init」ドメインで動作するようにできます。

initializer /sbin/init

また、デーモン系プログラムをアップデートした場合、 /etc/init.d/ ディレクトリ以下の起動・終了スクリプトを使用して restart や reload 等が実行されます。そのため、システムの起動時に実行される start とシャットダウン時に実行される stop だけでなく、 restart や reload 等に必要なアクセス許可も学習させておいてください。
（ /etc/init.d/ ディレクトリ以下の起動・終了スクリプトを initializer から除外あるいは信頼済みドメインに指定する方法でも構いません。ただし、対象となるデーモンプログラムが信頼済みドメインで動作してしまうと強制アクセス制御による保護ができないため、対象となるデーモンプログラムを initializer に指定するようにしてください。）

なお、ソフトウェアのアップデートのために一時的にサービスを停止させても構わない場合、上記の方法よりも以下の手順を採用するほうが良いと思います。（この場合でも start や stop に必要なアクセス許可は学習させておく必要があります。）

• アップデート対象となるパッケージをダウンロードする
• /etc/init.d/ ディレクトリ以下の起動・終了スクリプトを使ってサービスを停止させる
• アップデート対象となるパッケージをインストールする
• /etc/init.d/ ディレクトリ以下の起動・終了スクリプトを使ってサービスを開始させる

共有ライブラリの自動登録について

今週は、 ldconfig -NXp で出力されるファイル（実際にはシンボリックリンクなのでそのリンク先のファイル）を自動的に allow_read に登録するためのデーモンプログラムについて検討しています。 先日のバージョンとの違いは、「シンボリックリンクの一覧をファイルシステムから取得しないので動作が軽い」「ポリシーで allow_read に指定されていないものであっても登録するため、新たなシンボリックリンクが追加された場合でも（そのファイルが ldconfig により /etc/ld.so.cache に登録されている限り）対応できる」の２点です。

Linux では、「データファイルが漏洩したり改ざんされたりするのは困るが、ライブラリファイルは（誰でも自由に入手できるから）漏洩しても困ることは少ない」という事が言えると思います。そのため、「 /etc/ld.so.cache に登録されているライブラリファイルは、不特定多数のプログラムから参照できるように allow_read で指定しておいても大丈夫だろう」と考えています。なお、「このライブラリファイルは /etc/ld.so.cache に登録されているけども不特定多数のプログラムから参照できるようにはしたくない」という場合に備え、コマンドライン引数から特定のファイルを除外できるようにしてあります。

ISO イメージからインストールした Fedora Core 4 を yum -y update で最新状態にアップデートするという方法を試してみました。その結果、 /etc/ld.so.cache に登録されているファイルにアクセスできないというエラーは発生しませんでした。ただし、サービスの再起動や設定ファイルの再読み込みに必要なアクセス許可を学習させていなかったため、その他のエラーが発生しました。これらのエラーへの対処方法は次回説明します。

次回リリース時にこのプログラムを含めたいと思っていますが、オンラインアップデートをスムーズに行えるようにするにはもう少し検討が必要です。

spamassassin の扱いについて

スパムメールフィルタの spamassassin はデフォルトで /tmp/ ディレクトリにテンポラリのディレクトリを作成します。ただし、使われるディレクトリ名はバージョンによって異なっているようです。

RedHat Linux 9 に含まれている spamassassin では以下のようなパターンを使用します。

file_pattern /tmp/spamassassin-\$/ file_pattern /tmp/spamassassin-\$/.spamassassin/ file_pattern /tmp/spamassassin-\$/.spamassassin/auto-whitelist\*

Fedora Core 3 や Debian Sarge に含まれている spamassassin では以下のようなパターンを使用します。

file_pattern /tmp/spamd-\$-init/ file_pattern /tmp/spamd-\$-init/.spamassassin/ file_pattern /tmp/spamd-\$-init/.spamassassin/\*

上記は何も設定せずにデーモンを起動させただけで必要になるパターンです。実際にはもっとたくさんのパターンを指定する必要があるかもしれません。

squid の扱いについて

プロキシサーバの squid はキャッシュを保存するためのディレクトリをたくさん（デフォルトで１６×２５６＝４０９６個）作成します。 そのため、例外ポリシーでパターン化しておく必要があります。
キャッシュ用ディレクトリの場所とディレクトリの数は /etc/squid/squid.conf の cache_dir ディレクティブで指定されています。
キャッシュの保存場所が /var/spool/squid/ の場合、以下のようなパターンを例外ポリシーに指定してください。

file_pattern /var/spool/squid/\*/ file_pattern /var/spool/squid/\*/\*/ file_pattern /var/spool/squid/\*/\*/\*

/usr/sbin/squid の子プロセスとして起動される /usr/lib/squid/unlinkd （ファイルを削除するためのデーモン）に対してはファイルを削除するのに必要なアクセス許可を与えてください。
（バージョン 1.0.2 までの場合は allow_unlink ではなく 2 になります。）

allow_unlink /var/spool/squid/\*/\*/\*

Fedora Core 5 の readahead の扱いについて

Fedora Core 5 には、よく使われるファイルを予めＲＡＭ上にロードしておくことで動作を高速化させるための readahead というパッケージが付属しています。

/usr/sbin/readahead は /etc/rc.d/init.d/ ディレクトリにある起動スクリプトから実行され、 /etc/readahead.early.files および /etc/readahead.files に指定されているファイルに対して読み込みアクセスを行います。しかし、これらのファイルには多数のプログラムや設定ファイル等が指定されているため、 http://kumaneko-sakura.sblo.jp/article/328952.html で紹介した prelink と同様、パス名を保持するために大量のメモリを消費してしまうという問題を抱えています。

この問題を回避する方法は２通りです。簡単な方法は、以下のように chkconfig を使ってこれらのサービスが実行されないようにすることです。

chkconfig readahead_early off chkconfig readahead off

http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/fc5/?v=policy-sample に置いてあるポリシーのサンプルでは、この方法を採用しました。

もう１つの方法は、 /etc/readahead.early.files および /etc/readahead.files の内容を参考にしながら、 /usr/sbin/readahead のドメインに対してパターン化したアクセス許可を与えていくことです。いろいろなファイルを参照しているため、かなり緩めのパターン化が必要になると思います。まぁ、書き込みは行わないようなので緩めに許可しても大丈夫だとは思いますが。

現在までの目次

TOMOYO Linux とは
　　　http://kumaneko-sakura.sblo.jp/article/275769.html
TOMOYO Linux におけるパス名の表記法について
　　　http://kumaneko-sakura.sblo.jp/article/275773.html
　　　http://kumaneko-sakura.sblo.jp/article/277736.html
TOMOYO Linux におけるワイルドカードの使用について
　　　http://kumaneko-sakura.sblo.jp/article/277737.html
TOMOYO Linux におけるドメインについて
　　　http://kumaneko-sakura.sblo.jp/article/280111.html
　　　http://kumaneko-sakura.sblo.jp/article/281966.html
TOMOYO Linux におけるユーザとロールについて
　　　http://kumaneko-sakura.sblo.jp/article/284840.html
　　　http://kumaneko-sakura.sblo.jp/article/288778.html
TOMOYO Linux によるログイン認証の強化について
　　　http://kumaneko-sakura.sblo.jp/article/286949.html
TOMOYO Linux におけるデバイスファイルの保護について
　　　http://kumaneko-sakura.sblo.jp/article/291615.html
TOMOYO Linux における機能分類について
　　　http://kumaneko-sakura.sblo.jp/article/293567.html
TOMOYO Linux におけるマウント制限について
　　　http://kumaneko-sakura.sblo.jp/article/298507.html
　　　http://kumaneko-sakura.sblo.jp/article/298542.html
SYAORAN ファイルシステムの使い方について
　　　http://kumaneko-sakura.sblo.jp/article/301456.html
TOMOYO Linux における chroot 制限について
　　　http://kumaneko-sakura.sblo.jp/article/303669.html
読み込み専用ファイルシステムであることが原因でエラーとなったファイルアクセスを表示する機能について
　　　http://kumaneko-sakura.sblo.jp/article/303676.html
TOMOYO Linux におけるローカルポート番号の自動割り当ての制限について
　　　http://kumaneko-sakura.sblo.jp/article/304555.html
TOMOYO Linux における自発的権限放棄機能について
　　　http://kumaneko-sakura.sblo.jp/article/307244.html
TOMOYO Linux がタスク構造体に注目する理由について
　　　http://kumaneko-sakura.sblo.jp/article/307247.html
初期制御レベルの指定方法について
　　　http://kumaneko-sakura.sblo.jp/article/309752.html
ドメイン単位のアクセス制御機能について
　　　http://kumaneko-sakura.sblo.jp/article/311493.html
制御レベルについて
　　　http://kumaneko-sakura.sblo.jp/article/313521.html
エラーメッセージの表示について
　　　http://kumaneko-sakura.sblo.jp/article/313524.html
監査ログ機能について
　　　http://kumaneko-sakura.sblo.jp/article/315304.html
パス名のパターン化について
　　　http://kumaneko-sakura.sblo.jp/article/316432.html
無条件読み込み許可について
　　　http://kumaneko-sakura.sblo.jp/article/316434.html
ファイルに対するアクセス制御機能について
　　　http://kumaneko-sakura.sblo.jp/article/317819.html
ポリシーを保存する方法について
　　　http://kumaneko-sakura.sblo.jp/article/321755.html
テンポラリファイルの見つけ方について
　　　http://kumaneko-sakura.sblo.jp/article/321757.html
ドメイン遷移例外について
　　　http://kumaneko-sakura.sblo.jp/article/323687.html
信頼済みドメインについて
　　　http://kumaneko-sakura.sblo.jp/article/326379.html
シャットダウンを行うためのドメインの扱いについて
　　　http://kumaneko-sakura.sblo.jp/article/326412.html
TOMOYO Linux 上で動作するアプリケーションを開発する上でのお願い
　　　http://kumaneko-sakura.sblo.jp/article/328945.html
Fedora Core 3 の logrotate を実行するドメインの扱いについて
　　　http://kumaneko-sakura.sblo.jp/article/328948.html
Fedora Core 3 以降の prelink の扱いについて
　　　http://kumaneko-sakura.sblo.jp/article/328952.html
Java を使ったアプリケーションの扱いについて
　　　http://kumaneko-sakura.sblo.jp/article/333643.html
cron が実行するジョブを学習する方法について
　　　http://kumaneko-sakura.sblo.jp/article/333656.html
ケイパビリティに関する強制アクセス制御について
　　　http://kumaneko-sakura.sblo.jp/article/335939.html
　　　http://kumaneko-sakura.sblo.jp/article/339392.html
ローカルポートの使用に関する強制アクセス制御について
　　　http://kumaneko-sakura.sblo.jp/article/342723.html
リモートポートの使用に関する強制アクセス制御について
　　　http://kumaneko-sakura.sblo.jp/article/342725.html
シグナルの使用に関する強制アクセス制御について
　　　http://kumaneko-sakura.sblo.jp/article/342728.html
ポリシーを保存する方法について
　　　http://kumaneko-sakura.sblo.jp/article/347127.html
ポリシーを再読み込みする方法について
　　　http://kumaneko-sakura.sblo.jp/article/350063.html
コマンドラインオプションの指定を制限する方法について
　　　http://kumaneko-sakura.sblo.jp/article/354406.html
機密度に応じた文書の管理方法について
　　　http://kumaneko-sakura.sblo.jp/article/358391.html
ランダムにネットワークポート番号を選択するサービスについて
　　　http://kumaneko-sakura.sblo.jp/article/362567.html
HTTP や FTP 等でアクセスを許可するファイルを指定する方法について
　　　http://kumaneko-sakura.sblo.jp/article/365765.html
バニラカーネル以外への適用について
　　　http://kumaneko-sakura.sblo.jp/article/367573.html
カーネルの動作確認用のツールについて
　　　http://kumaneko-sakura.sblo.jp/article/369183.html
ログイン認証の強化（CERBERUS）について
　　　http://kumaneko-sakura.sblo.jp/article/372199.html
　　　http://kumaneko-sakura.sblo.jp/article/388532.html
　　　http://kumaneko-sakura.sblo.jp/article/390597.html
　　　http://kumaneko-sakura.sblo.jp/article/401950.html
　　　http://kumaneko-sakura.sblo.jp/article/407594.html
　　　http://kumaneko-sakura.sblo.jp/article/409826.html
　　　http://kumaneko-sakura.sblo.jp/article/411897.html
　　　http://kumaneko-sakura.sblo.jp/article/427594.html
　　　http://kumaneko-sakura.sblo.jp/article/429562.html
　　　http://kumaneko-sakura.sblo.jp/article/431430.html
scp/sftp への対処について
　　　http://kumaneko-sakura.sblo.jp/article/434756.html
ssh/scp/sftp の自動実行について
　　　http://kumaneko-sakura.sblo.jp/article/438146.html
パターンマッチングについて
　　　http://kumaneko-sakura.sblo.jp/article/440824.html
　　　http://kumaneko-sakura.sblo.jp/article/442394.html
シャットダウン処理について
　　　http://kumaneko-sakura.sblo.jp/article/446683.html
cardmgr が作成するデバイスファイルについて
　　　http://kumaneko-sakura.sblo.jp/article/449167.html
Targeted Policy の作り方について
　　　http://kumaneko-sakura.sblo.jp/article/450207.html
logrotate のアクセス許可を学習させる方法について
　　　http://kumaneko-sakura.sblo.jp/article/454136.html
anacron のアクセス許可を学習させる方法について
　　　http://kumaneko-sakura.sblo.jp/article/454139.html
効率的にパス名のパターン化を行う方法について
　　　http://kumaneko-sakura.sblo.jp/article/459882.html
gcc が使用するパス名のパターン化について
　　　http://kumaneko-sakura.sblo.jp/article/461913.html
詳細な書き込みアクセス権限のチェックについて
　　　http://kumaneko-sakura.sblo.jp/article/463433.html
バニラカーネル以外への適用について
　　　http://kumaneko-sakura.sblo.jp/article/470145.html
Shared Subtree のサポートについて
　　　http://kumaneko-sakura.sblo.jp/article/475717.html
cron のアクセス許可を学習させる方法について
　　　http://kumaneko-sakura.sblo.jp/article/477221.html
パッケージのアップデートに伴うパス名の変化について
　　　http://kumaneko-sakura.sblo.jp/article/479846.html
　　　http://kumaneko-sakura.sblo.jp/article/485792.html

パッケージのアップデートに伴うパス名の変化について（続）

TOMOYO Linux はパス名（ディレクトリ名＋ファイル名）に基づくアクセス制御を行うため、パッケージのアップデート等によりパス名が変化した場合には、ポリシーを更新する必要があります。

共有ライブラリの場合、パス名の内、ファイル名の部分だけが変化します。（逆に、ディレクトリ名が変化することはまずありません。）ほとんどの共有ライブラリはシンボリックリンクを経由してアクセスされます。そのため、バージョンアップをしても、シンボリックリンクのリンク先が変化するだけで、シンボリックリンク自体のパス名は変化しません。つまり、シンボリックリンクのリンク先がどのように変化するかを監視するのが有効であり、機械的に変化を一覧表示することができます。

先週から、シンボリックリンクの一覧を取得し、そのリンク先が allow_read で指定されたファイルであるものに関して、リンク先が更新された場合に新しいリンク先を指定して allow_read の登録を行うためのデーモンプログラムについて検討しています。
このデーモンを起動してからアップデートを実行することで、シンボリックリンクのリンク先が変化するだけの更新（新たなシンボリックリンクの追加を伴わない更新）であれば自動的に allow_read を更新することができるようになります。
allow_read には、主に ldconfig に登録されている共有ライブラリを指定するため、一瞬でもアクセスできなくなるとプログラムを実行できなくなってしまう可能性があります。そのため、 allow_read で指定されるファイルは即時に最新のパス名を指すようにする必要があります。
カーネル 2.4 系でも動く必要がある点と、 dnotify の使い方を理解していないので、１秒間隔のポーリングという非効率的な方法で実現しています。ポーリング方式なので、約１秒の遅延が起きてしまうのが心配です。この遅延時間が許容範囲なのかどうかは今後実験して確かめる予定です。

パッケージのアップデートに伴うパス名の変化について

TOMOYO Linux はパス名（ディレクトリ名＋ファイル名）に基づくアクセス制御を行うため、パッケージのアップデート等によりパス名が変化した場合には、ポリシーを更新する必要があります。

安全確実な方法は、パッケージのダウンロードまでを行い、安全な環境を用意（ネットワークから切断）した上で「確認モード」に変更してからパッケージのアップデートを行い、アップデートされたアプリケーションを実際に動作させてアクセス許可の不足がないかどうかを確認することです。
VMware 等、同一ハードウェア構成の環境を２台用意できる場合は、コピーされた環境に対してアップデートを行い、アクセス許可の不足がないかどうかを確認することができます。

しかし、アップデート前後でパス名がどのように変化するかを予め把握できている場合には、アップデート前にポリシーファイルに新しいパス名を追加して再読み込みする方法も使えます。 ただし、パス名が変化するだけでなく、依存関係も変化する場合もありえますので、絶対確実な方法とは言えません。

Windows ではライブラリファイルのバージョンはファイルの中に埋め込まれているので、バージョンアップしてもパス名が変化することは滅多にありません。
TOMOYO Linux としては、 Windows のようにライブラリファイルのパス名が固定されているほうが嬉しいわけです。

cron のアクセス許可を学習させる方法について

http://kumaneko-sakura.sblo.jp/article/333656.html で cron が実行するジョブに必要なアクセス許可を学習させる２通りの方法を紹介しましたが、次回の手順書では /etc/crontab を編集する方法を採用することにしました。

/etc/crontab を開き、以下のようにジョブの実行間隔を５分に変更してください。 １分間隔だと前回のジョブが終了する前に次回のジョブが開始されてしまう可能性が高いので、適当な時間間隔を設定する必要があります。 pstree を実行すると、 cron のジョブを実行中かどうか確認できます。もし、 pstree を実行すると常に cron のジョブが表示されるようであれば、時間間隔を長くしてください。

変更前

SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # run-parts 01 * * * * root run-parts /etc/cron.hourly 02 4 * * * root run-parts /etc/cron.daily 22 4 * * 0 root run-parts /etc/cron.weekly 42 4 1 * * root run-parts /etc/cron.monthly

変更後

SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # run-parts */5 * * * * root run-parts /etc/cron.hourly */5 * * * * root run-parts /etc/cron.daily */5 * * * * root run-parts /etc/cron.weekly */5 * * * * root run-parts /etc/cron.monthly

この状態でしばらく放置して、必要なアクセス許可が学習されるのを待ちます。

強制モードでの稼動を始める前までに、 /etc/crontab に加えた変更を元に戻すようにしてください。

Shared Subtree のサポートについて

カーネル 2.6.15 では shared subtree という機能が追加されました。
これは、マウントポイント単位で共有するしない等を設定することで、 それぞれのプロセスが異なる名前空間を持っていても（例えば） CD-ROM にアクセスするために使われるマウントポイントを それぞれのプロセスから共通してアクセスできるようにする機能のようです。 （詳しいことは私もまだ理解していません。）

そのために、 mount 操作に対していくつかの構文が追加されたのですが、 TOMOYO Linux version 1.0.2 のマウント制限機能では新しい構文を認識していませんでした。
次のバージョンでは新しい構文を認識できるようになります。

バニラカーネル以外への適用について

http://kumaneko-sakura.sblo.jp/article/367573.html でバニラカーネル以外のカーネルに対して TOMOYO Linux のパッチを適用することについて触れました。 その後もパッチの作成を続けており、３／１４現在、以下のバージョン用のパッチがあります。

RedHat Linux 9 用

• 2.4.20-43.9.legacy

Debian Sarge 用

• 2.4.27-10sarge1
• 2.6.8-16sarge1

Fedora Core 3 用

• 2.6.12-1.1381_FC3

Fedora Core 4 用

• 2.6.15-1.1831_FC4

Fedora Core 5 test 3 用

• 2.6.15-1.1977_FC5
• 2.6.15-1.2041_FC5

バニラカーネル用

• 2.4.30
• 2.4.31
• 2.4.32
• 2.6.11
• 2.6.12
• 2.6.13
• 2.6.14
• 2.6.15
• 2.6.15.4
• 2.6.16-rc6

ただし、最終的に次回リリースにどれだけ多くのパッチを含めることができるのかはまだ不明です。

詳細な書き込みアクセス権限のチェックについて

次期バージョンでは、詳細な書き込みアクセス権限のチェックを行えるようにする予定です。

version 1.0.2 まではファイルやディレクトリに対するアクセス許可の粒度は read/write/execute の３種類のみでした。そのため、 write 権限の中には

• open(O_WRONLY)
• open(O_RDWR の WR 部分）
• open(O_TRUNC)
• open(O_CREAT)
• sysctl(WRITE)

の他に

• mkdir
• rmdir
• unlink
• mksock
• mkfifo
• mkchar
• mkblock
• link
• symlink
• rename
• create
• truncate

が含まれていました。

しかし、あるファイルへの write 権限があればそのファイルを削除して同名の異なるファイルを作成できてしまうのはセキュリティ上危険です。例えば、通常ファイルを削除して、同じ名前でハードディスクを指すブロックデバイスファイルを作成される可能性があります。通常のファイルを読み書きする許可を意図していたのに、侵入者がファイルを作り直すことで、そのパス名を使ってハードディスクを直接読み書きできるような状況が起こりうるのです。

このような状況が発生する可能性を減らすために、ケイパビリティ（http://kumaneko-sakura.sblo.jp/article/335939.html）を使ってデバイスファイルを作成することができるドメインを制限していましたが、パス名による制限ではないため充分とはいえない状況でした。

次のバージョンでは write 権限は以下の３種類だけを指すようになります。

• open(O_WRONLY)
• open(O_RDWR の WR 部分)
• sysctl(WRITE)

そして、新規に以下の権限が追加されます。

• allow_mkdir
• allow_rmdir
• allow_unlink
• allow_mksock
• allow_mkfifo
• allow_mkchar
• allow_mkblock
• allow_link
• allow_symlink
• allow_rename
• allow_create
• allow_truncate

これらの細分化された書き込みアクセス権限のチェックが行われるようになることで、パス名による制限ができるようになります。（実際には「キャラクタ型デバイスファイル」「ブロック型デバイスファイル」という種別だけでは不十分かもしれませんが、現時点ではデバイス番号まではチェックしていません。今後、必要であると判断したらチェックするようにしようと思います。）

実際にこれらの権限を有効にした状態で取得したポリシーのサンプルを http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/?v=policy-sample で眺めることができます。

gcc が使用するパス名のパターン化について

gcc が利用可能な状態でサーバとして動作させるというのはセキュリティ上望ましくないのですが、やむを得ず gcc を利用可能な状態にする必要がある場合、 gcc を実行するためのドメインに対して環境変数 TEMP または TMP を明示することを推奨します。

例えば、

gcc -Wall -O3 test.c

を実行すると /tmp/ 直下に cc\?\?\?\?\?\?.c cc\?\?\?\?\?\?.o cc\?\?\?\?\?\?.s cc\?\?\?\?\?\?.le cc\?\?\?\?\?\?.ld 等のパターンを持った一時ファイルが生成されます。そのため、

file_pattern /tmp/cc\?\?\?\?\?\?.\*

というパターンでグループ化することができます。しかし、 gcc とは無関係なプログラムがこのようなパターンを必要とした場合、 gcc が生成した一時ファイルにもアクセスできるようになってしまいます。そのため、 /tmp/ 直下ではなく例えば /tmp/gcc/ 直下に一時ファイルが作成されるように

TMP=/tmp/gcc/ gcc -Wall -O3 test.c # または TEMP=/tmp/gcc/ gcc -Wall -O3 test.c

のように環境変数を指定した上で gcc を実行することで

file_pattern /tmp/gcc/cc\*

のように gcc 専用のパターンでグループ化できるようになるため、 gcc に関連する一時ファイルに他のプログラムからアクセスできるようになってしまう可能性を低くすることができます。（ /tmp/gcc/ ディレクトリは予め作成しておいてください。）

なお、この手法は gcc のみに限定されるものではなく、環境変数を使って一時ファイルを作成する場所を指定できるプログラム全般に適用できます。