SYAORAN ファイルシステムについて

http://kumaneko-sakura.sblo.jp/article/301456.html で紹介した SYAORAN ファイルシステムですが、 2.6 カーネルでは必要に応じてデバイスファイルを作成する udev という仕組みが使われているために、 makesyaoranconf で全てのエントリをピックアップできるとは限らないという問題がありました。

そのため、 TOMOYO Linux 1.3 では、エラーが発生した場合にエラーメッセージを表示するように変更されました。このエラーメッセージは makesyaoranconf の実行時には存在しなかったエントリをピックアップするのに使うことができます。このエラーメッセージはデバッグレベルで表示されるため、通常の設定ではコンソールには表示されません。このエラーメッセージを表示するには、 dmesg | grep ^SYAORAN-ERROR: を実行してください。

随所で小狼の綴りは SYAORAN ではなく Xiaolang だろという書き込みを見かけますが、ＣＣさくら第２巻Ｐ５７によると、 SYAORAN とのことです。

ログファイルの保護機能について

TOMOYO Linux 1.3 では、ログファイルのように追記専用で使用されるファイルを保護するために deny_rewrite 構文と allow_rewrite 構文が追加されています。

deny_rewrite 構文で指定されたパス名は allow_rewrite 構文で指定されない限り、既に記録されている部分を書き換えできないようになります。

TOMOYO Linux はパス名でアクセスの可否を判断します。そのため、ハードリンクされたファイルの片方のパス名に対して deny_rewrite を指定しても、他方のパス名に deny_rewrite が指定されていなければ、他方のパス名経由で既に記録されている部分を書き換えされてしまう可能性があることに注意してください。

ドメイン名を安全にコマンドラインに渡す方法について

TOMOYO Linux 1.3 以降では setprofile というコマンドを使ってドメインに割り当てるプロファイルを変更することができます。コマンドラインパラメータとしてドメイン名を渡すので、安全に渡す方法について紹介します。

ドメイン名は <kernel> で始まりますが、そのまま setprofile -r 1 <kernel> /sbin/initのように指定してしまうと < や > がシェルのリダイレクト記号と解釈されてしまいます。
カレントディレクトリに kernel という名前のファイルが存在していると setprofile コマンドが実行されて /sbin/init の内容が失われてしまいますので注意してください。
通常は、 setprofile -r 1 '<kernel> /sbin/init' のようにシングルクォートで囲んでやれば大丈夫ですが、この方法ではドメイン名にシングルクォートが含まれている場合に正しく動作できません。

どのようなドメイン名が来るか不明な場合には、
tr '\n' '\0' | xargs -0 setprofile -r 1
のように実行してから、ドメイン名を改行区切りで列挙してください。
標準入力から入力する場合は
tr '\n' '\0' | xargs -0 setprofile -r 1
のように実行してから、ドメイン名を改行区切りで列挙して、最後に Ctrl-D を押してください。
また、 domainlist.txt というファイルから入力する場合は
tr '\n' '\0' < domainlist.txt | xargs -0 setprofile -r 1
のように実行してください。

なお、１行しか指定しない場合は tr '\n' '\0' の処理は不要です。
標準入力から入力する場合は
xargs -0 setprofile -r 1
のように実行してから、ドメイン名を１行指定して、最後に Ctrl-D を押してください。

TOMOYO Linux 1.3 以降におけるドメインについて

長いこと Tips をサボっていましたが、連載も始まったことですので、再開したいと思います。

TOMOYO Linux におけるドメインについて http://kumaneko-sakura.sblo.jp/article/280111.html

TOMOYO Linux におけるドメインについて（続） http://kumaneko-sakura.sblo.jp/article/281966.html

で TOMOYO Linux のドメインについて説明しましたが、 TOMOYO Linux 1.3 で大きな変更がありました。

TOMOYO Linux 1.3 では、「ポリシーを積み上げるみたいに順次追加していける形にアクセス制御をできるようにして欲しい」との要望を受けて、ドメイン単位でアクセス制御の方法を指定できるようになりました。 1.2 まではシステム全体で１種類のアクセス制御の方法を指定していましたが、 1.3 以降ではドメイン単位でアクセス制御の方法を指定できます。

これにより、万一特定のアプリケーションが動作しないという場合があっても、 SELinux のようにシステム全体で強制アクセス制御の機能を無効化する必要がなくなりました。 TOMOYO Linux 1.3 以降を使うのであれば「動かないから TOMOYO Linux を丸ごと無効化する」という選択肢を選ぶことは無いでしょう。

TOMOYO Linux 1.3.1 では、「ドメイン単位でアクセス制御を行うかどうかを指定できるのだから、もはや信頼済みドメイン機能は不要だろう」ということで、信頼済みドメイン機能は廃止されました。代わりに、信頼済みドメインの仕様の内、ドメイン遷移が発生しないという部分だけを実装しました。それが、 keep_domain 構文です。 keep_domain 構文で指定されたドメインに到達すると、 initializer 構文で指定されたプログラムが呼ばれない限り、そのドメインに留まるようになりました。この機能は、ログイン後の一連の操作を単一のドメインで行わせる場合に威力を発揮することでしょう。

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

1.3.1 は 1.3 とほぼ同じですが、 http://kumaneko-sakura.sblo.jp/article/1695760.html で書いたとおり、「信頼済みドメイン機能」を廃止しました。内容については http://lists.sourceforge.jp/mailman/archives/tomoyo-users/2006-November/000149.html や http://lists.sourceforge.jp/mailman/archives/tomoyo-users/2006-December/000153.html を参照してください。

TOMOYO Linux 1.2 時点の内容ですが、１２／８に発売された技術評論社「ネットワークセキュリティ Expert 5」に「TOMOYO Linux の秘密」として、実装面を中心に解説が掲載されています。
また、 TOMOYO Linux 1.3.1 の内容で、技術評論社「Software Design 2007年1月号」から「今日から使えるセキュアOS TOMOYO Linuxの世界」として使い方を中心に連載が始まります。
http://tomoyo.sourceforge.jp/wiki/ には Wiki が設置されています。どうぞご利用ください。

いよいよ、本格的に普及活動を始められるのかなぁ？

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

内容については http://lists.sourceforge.jp/mailman/archives/tomoyo-users/2006-November/000125.html や http://lists.sourceforge.jp/mailman/archives/tomoyo-users/2006-November/000140.html を参照してください。

今回のリリースでやり残したことというと、信頼済みドメインの扱いをどうすべきかがあります。今まではアクセス制御を行わないドメインを作成するには信頼済みドメインを利用するしか方法が無かったのですが、今後はアクセス制御を行わないプロファイルを割り当てることで実現できるため、信頼済みドメインを利用する必要性が無くなってしまいました。複数プロファイルと信頼済みドメインを混在させると混乱の元になると思うので、 make_exception.sh から trust_domain の処理を外しました。（ 1.2 との互換性のために信頼済みドメイン機能は残っています。）今後は、アクセス制御の方法はプロファイルだけに従い、 initializer ディレクティブで指定されたプログラムが実行されるまでドメイン遷移しないための仕組みを用意するのが良いのかもしれません。

報道発表に関するコメントへのコメント

報道発表

• http://www.nttdata.co.jp/release/2006/101300.html

それに対するコメント

• http://slashdot.jp/security/06/10/17/0717203.shtml
• http://www.itmedia.co.jp/enterprise/articles/0610/16/news099.html
• http://opentechpress.jp/news/06/10/16/0937251.shtml
• http://japan.zdnet.com/news/sec/story/0,2000056194,20273867,00.htm

関連する論文

• http://sourceforge.jp/projects/tomoyo/document/winf2005.pdf
• http://sourceforge.jp/projects/tomoyo/document/winf2005-en.pdf

ブルートフォース対策の部分が目立ちすぎてしまいましたが、セキュアＯＳを使っている意味はそれだけではありません。ブルートフォースなどの「正規の認証手順を経た侵入」への対策とバッファオーバーフローなどの「正規の認証手順を経ない侵入」への対策を同時に実現している点が新しいのです。セキュアＯＳ（が備える強制アクセス制御機能）はユーザ認証の強化にも使えるということを示すことで、セキュアＯＳの利点を知ってもらいたかったのです。

既存のブルートフォース対策は試行可能回数を減らすことしか考えていません。セキュアＯＳならば、少ない試行回数で侵入に成功した場合にも対処できます。

脆弱性への意識が薄いと感じました。セキュアＯＳの普及が進まない一因でもあるでしょう。まだまだ「既存の認証方式で充分」「脆弱性が見つかったらアップデートすればよい」という考えが根強いようです。最近はゼロディアタックという言葉をよく聞きますが、既存の認証方式ではゼロディアタックに対処できません。

認証失敗ログと iptables を連動させてＩＰアドレス単位で一定期間アクセスを禁止させる対策が殆どです。でも、クライアントがＤＨＣＰ環境の場合には困ります。ダイアルアップ接続をすることもあるでしょう。攻撃者が使ったＩＰアドレスが数十分後には正規利用者に割り当てられてしまうかもしれません。

認証に失敗したらアカウントをロックするのが良いと言われてロックするようにしたら、今度は故意に認証を失敗させることで正規利用者に利用させないという攻撃も出現しました。追加認証を行なわせれば、最初の認証を突破されても被害を受けないので、認証に失敗してもロックする必要がありません。

秘密鍵が漏洩するなんて起こらないというコメントもありました。公開鍵認証はパスワードを紙に書いて保管しているようなものです。常に漏洩するかもしれないというリスクを抱えています。ＨＤＤに置いておく限り、ウイルスやスパイウェアによる漏洩は起こりえます。 SSH サービスに接続するクライアントは Linux だけではありません。 Windows で接続することもあります。 Antinny のようなウィルスに感染してハードディスクの内容を丸ごと暴露される可能性もあります。また、スパイウェアがこっそり秘密鍵を漏洩させてしまうかもしれません。秘密鍵をパスワードで保護することはできても、気休め程度にしかならないという意見もあります。

近年、シンクライアントというものが流行しています。認証に使うものをサーバ側に用意しておけば、認証に使う情報がクライアントから漏洩することを防げます。

リムーバブルメディアを紛失するかというコメントもありました。ＨＤＤに置かない限り、リムーバブルメディアに置くことになります。ノートＰＣと一緒に携帯することはあるでしょう。

＜タイミングを考慮した認証について＞

これは、 honey.c の焼き直しです。（蜂蜜を焼くとどんな香り？（笑）） honey では認証情報がソースコード中にハードコーディングされているため、インタプリタとして作成した方が扱いやすいと思って開発したものです。

http://osdn.dl.sourceforge.jp/tomoyo/22559/ccs-tools-1.3-20061111.tar.gz の中の timeauth.c がソースコードです。スクリプトの解釈処理のため長く見えますが、それを除けば正味５０行程度でしょう。これならセキュリティの専門家でなくても作成できると思います。

＜携帯電話を使った認証について＞

追加認証を行なうのに携帯電話の利用は必須ではありません。でも、誰でも持っている（私は持っていないけど（笑））装置を使えば、別途専用の装置を導入せずに済みます。紛失する可能性はありますが、注意を払っていると思います。お財布ケータイとか言われている時代ですから、肌身離さず持っているでしょう。

http://osdn.dl.sourceforge.jp/tomoyo/22559/ccs-tools-1.3-20061111.tar.gz の中の mailauth.c がソースコードです。

デモで使用するシステムにはメール送信時に使う認証情報を残したくないので、 HTTP でアクセス可能なサーバに CGI を設置して行いました。以下がそのソースコードですが、そのまま使うとスパムメールの発射台にされてしまいますのでご注意ください。

#!/usr/local/bin/perl

open(MAIL, "| /usr/sbin/sendmail -t");
print MAIL "From: sender\@domain\n";
print MAIL "To: " . $ENV{'QUERY_STRING'} . "\n";
print MAIL "Subject: Your password\n";
print MAIL "\n";
while ($_ = <STDIN>) { print MAIL $_; }
close(MAIL);
print "Content Type: text/plain\r\n\r\n";

この CGI 経由で送るには、
echo message | curl --data-binary @- http://server/path_to_cgi?receiver@domain
のように指定します。（MAIL_COMMAND として curl --data-binary @- http://server/path_to_cgi?receiver@domain の部分を指定します。）

scp や sftp にログイン認証の強化を適用する方法について

ssh サービスを保護する方法はたくさんあると思います。

http://kumaneko-sakura.sblo.jp/article/1275428.html では、接続元ポート番号を制限することで ssh サービスが稼動していることをポートスキャンにより捕捉されないようにする手法について紹介しました。

でも、利用者が不特定多数である場合、接続可能な接続元ポート番号の範囲を隠し続けることは困難です。誰かがうっかりポート番号の範囲を洩らしてしまうかもしれません。
そこで、 http://kumaneko-sakura.sblo.jp/article/372199.html では、標準の ssh ログイン認証後に追加の認証を行わせることでブルートフォース等による不正侵入に対抗できるようにする手法について紹介しました。

ただし、この手法はログイン後に対話的な操作ができることを前提にしているため、 scp や sftp のようにログイン後に直ちに処理を行うプログラムには適用できませんでした。そのようなプログラムへの対策として http://kumaneko-sakura.sblo.jp/article/434756.html では、アクセス可能な範囲を限定するという手法について紹介しました。

今回、いくらか制約が増えるものの scp や sftp のようなプログラムにこの手法を適用することに成功したので紹介します。主な制約は以下の点です。

• ssh ログイン時に仮想端末が割り当てられないため、「プロンプトが表示されない」「 Ctrl-D でシェルを終了できない」など、操作性が劣る。
• クライアント側とサーバ側の両方に専用のプログラムを用意する必要がある。
• クライアント側プログラムは ssh プログラムを直接呼び出してはいけない。
• サーバ側のログインシェルとして既存のシェルを使うことができない。

使用するプログラムは以下の３つです。説明用に解りやすい名前にしてありますが、実際に導入する際は他の名前にして構いません。

• ssh_wrapper （クライアント側で使用）
• login_shell （サーバ側で使用）
• scp+sftp_wrapper （サーバ側で使用）

ログインシェルに -c オプションを指定して実行されるプログラムは、標準入出力の 1 バイト目からそのプログラム用のデータがやり取りされることを期待しています。そのため、プロンプトのように予期せぬデータが紛れ込むと正しく動作することができません。
今回の手法は、標準入出力を用いてやり取りされるプログラム用のデータの前に認証用のデータを挿入する必要があるので、どこからプログラム用のデータが始まるのかをはっきりさせなければいけません。そのため、如何に確実に同期を取るかが重要です。
ssh_wrapper と scp+sftp_wrapper ではプリアンブルとして 256 バイトの連続する 0 が出現したらプログラム用のデータの始まりであると判断するようにしています。もし、認証を行っている間にプリアンブルと同じデータが出現してしまった場合、正しく動作することができなくなります。

scp や sftp は -S オプションを使って ssh プログラムの場所を指定することができます。今回の手法は、このオプションを使って ssh の代わりに ssh_wrapper を実行し、 ssh_wrapper の中で対話的な操作を行わせます。

scp+sftp_wrapper.c を scp+sftp_wrapper.c として保存し、以下のようにコンパイルしてください。

gcc -Wall -O3 -o /bin/scp+sftp_wrapper scp+sftp_wrapper.c

login_shell.c を login_shell.c として保存し、以下のようにコンパイルしてください。

gcc -Wall -O3 -o /bin/login_shell login_shell.c

ssh_wrapper.c を ssh_wrapper.c として保存し、以下のようにコンパイルしてください。

gcc -Wall -O3 -o /bin/ssh_wrapper ssh_wrapper.c

サーバ側の準備として、ユーザのログインシェルを変更します。例えば demo というユーザの場合は以下のようにします。

usermod -s /bin/login_shell demo

クライアント側は、以下のように scp や sftp を起動する際に　-S オプションを使って ssh ではなく ssh_wrapper を使うようにします。

sftp -S /bin/ssh_wrapper [e-mail]

scp -p -S /bin/ssh_wrapper [e-mail]:/home/demo/test.txt ~/

ssh でログインすると、 login_shell が -c というオプションを指定された状態で実行されます。
login_shell は -c というオプションで指定された処理を環境変数 ORIGINAL_COMMAND に保存してから /bin/sh を実行します。

この段階で追加の認証を行うようにしてください。振る舞いを制限するには TOMOYO Linux の強制アクセス制御機能を使ってください。

そして、追加の認証が終わって本来の処理を行う準備が整ったら、 scp+sftp_wrapper を実行してください。

/bin/scp+sftp_wrapper

scp+sftp_wrapper はプリアンブルを送受信して同期を確認後、環境変数 ORIGINAL_COMMAND で指定された処理を実行します。処理が終了後、 ssh 接続が閉じられるはずです。結果的に、ログインシェルに -c コマンドで渡された処理を実行後切断するのと同等の処理が行われたことになります。

今回のプログラムでは ssh_wrapper の中で端末を開いて手動で追加認証情報をやり取りさせるようにしましたが、 ssh_wrapper を改造すれば自動で追加認証情報をやり取りできるようにすることも可能でしょう。お好みの認証方式を作成して使ってください。既存の認証方式に囚われないのが利点ですので、思う存分、あなただけのアイデアを活用してください。

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

内容については http://lists.sourceforge.jp/mailman/archives/tomoyo-users/2006-August/000102.html や http://lists.sourceforge.jp/mailman/archives/tomoyo-users/2006-September/000105.html を参照してください。

今までは起動時から電源が切れるまでのシステム全体を強制アクセス制御の対象にする手順を中心にしたドキュメント構成になっていましたが、ネットで検索してみるとリモートログイン操作の保護手順について触れているものは見当たりませんでした。
そのため、今回は SELinux の Targeted Policy のように特定のデーモン以下だけを強制アクセス制御の対象にする手順を http://tomoyo.sourceforge.jp/ja/1.2/targeted-install.html として追加しました。この方法だと、 cron のようにポリシー策定のために手間がかかるものを省略することができるので、導入が簡単になります。

今回のバージョンアップではドメイン単位のアクセス制御に関して、個々のアクセス許可に対して条件指定が可能になりました。
今まではバッファオーバーフローなどで SSH 認証を回避されたら root としてログインされてしまうため、 root としてログインされることを前提とした追加認証などの設定を行うようにしてきました。
しかし、 1.2 では、 if task.uid!=0 task.egid!=0 のように条件を追加することで、バッファオーバーフローなどで SSH 認証を回避されたとしても root としてログインシェルを起動されることを禁止できるようになりました。もちろん、追加認証は無駄にはなりません。

http://kumaneko-sakura.sblo.jp/article/284840.html では、ユーザ毎にドメインを分割する方法を紹介しましたが、 DAC のパーミッションでしか実行を制限できなかったものが、 MAC のポリシーによっても実行を制限できるようになりました。例えば、 SAKURA のユーザＩＤが 500 の場合、 1 /ich/bin/SAKURA if task.uid=500 のように指定することで、 root であっても /ich/bin/SAKURA を実行できなくなりました。

ユーザやロール単位でドメインを分割できない FTP サービスや Windows ファイル共有サービスに関しても、 if task.uid=path1.uid や if task.euid=path1.uid のような条件を追加することで、自分の所有するファイルにのみアクセスできるようになりました。

パターンマッチングも強化され、例えば MySQL のように拡張子によって読み書きを必要とするファイルと読み込み専用で大丈夫なファイルとが同じディレクトリに存在しても対応できるようになりました。

ネットワークのアクセス制御では、ポート番号だけでなくＩＰアドレスも考慮した制御が可能になりました。 iptables ほどの詳細な制御はできませんが、ドメイン単位の iptables のような機能です。これを利用することで、本来通信の必要の無い相手との通信を遮断できるようになり、ワームの拡散を制限できるようになりました。

ポリシーエディタで効率よくアクセス許可を追加する方法について

TOMOYO Linux には ncurses による CUI 環境用のポリシーエディタが付属しています。
ncurses だとターミナルの種類によってスキャンコードが異なる場合があるので、環境によってはうまくカーソルを移動させることができません。アクセス許可を追加する場合に思い通りにカーソルを動かせなくてストレスが溜まることもあるかと思います。
このポリシーエディタは、 Windows から（UTF-8対応版ではない） TeraTerm で SSH 接続して操作することを想定してキーバインディングが設定されているので、可能であればそのような環境を用意すると入力が楽になります。

しかし、このポリシーエディタは、コピー＆ペーストでどんどんアクセス許可を追加できるような構造になっているのです。
例えば、 Apache に対して DocumentRoot 以下の読み込みアクセス許可を与える場合は以下のようになるでしょう。

4 /var/www/html/\* 4 /var/www/html/\*/\* 4 /var/www/html/\*/\*/\* 4 /var/www/html/\*/\*/\*/\* 4 /var/www/html/\*/\*/\*/\*/\* 4 /var/www/html/\*/\*/\*/\*/\*/\*

そして、アクセス許可の追加をするには a ボタンを押してからアクセス許可の内容を入力するわけです。つまり、

a 4 /var/www/html/\* a 4 /var/www/html/\*/\* a 4 /var/www/html/\*/\*/\* a 4 /var/www/html/\*/\*/\*/\* a 4 /var/www/html/\*/\*/\*/\*/\* a 4 /var/www/html/\*/\*/\*/\*/\*/\*

のように先頭に a を付けた状態で NotePad 等に記述しておき、複数行まとめてコピーしてポリシーエディタを実行中のウィンドウにペーストしてやれば、一発で追加できるわけです。

また、上記のパターンのように必ず追加する必要がある内容はファイルに保存しておくことをお勧めします。そうしておけば、ポリシーを１から再取得する際に再利用できて効率的です。

コピー＆ペーストのためにリモートの GUI 環境を要求するのは反則ですか？（笑）

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

今回のリリースではシンボリックリンクのままドメインを定義できるようにする機能が導入されました。

従来は常にシンボリックリンクを解決したプログラム名を使用するため、異なるドメインに分岐させたい場合には、ハードリンクやコピーを作成しなければいけませんでした。
しかし、ハードリンクやコピーを作成すると、パッケージのアップデートをしても１個だけしか更新されないという問題がありました。（例えば /sbin/pidof という /sbin/killall5 へのシンボリックリンクを削除して /sbin/killall5 のコピーを作ると、アップデートにより /sbin/killall5 が更新されても /sbin/pidof が更新されないままになってしまいます。）
version 1.1.3 ではシンボリックリンクを作成してポリシーで alias 指定をするだけでよいので、パッケージのアップデートによる問題を回避することができます。

また、 http://kumaneko-sakura.sblo.jp/article/388532.html では /bin/bash を任意の場所にコピーしてログインシェルを変更することによりシェルコード対策を行えることについて触れましたが、今回の機能追加により、コピーする必要がなくなったため、上述のアップデートによる問題を回避できるようになりました。ラッパープログラムも使わないで済むようになったわけです。

技術的な話をすると、 execve() には filename と argv[] と envp[] を渡せますが、たまに argv[0] の内容によって振る舞いを変化させるプログラムが存在します。 busybox はその一例です。
TOMOYO Linux のドメイン遷移は filename の内容に基づいて行われます。たいていの場合、 filename と argv[0] は同じ内容なので問題無いのですが、バイナリラッパのように意図的に filename と argv[0] で異なる内容を指定する場合があります。例えば、 filename に /sbin/busybox へのシンボリックリンクである /bin/ls を、 argv[0] に /sbin/busybox へのシンボリックリンクである /bin/cat を指定した場合、 /bin/ls のドメインで /bin/cat として振る舞うというちぐはぐな状況が発生します。攻撃者が意図的に filename と argv[0] で異なる内容を指定できれば、穴になってしまうわけです。
これは TOMOYO Linux 1.1.3 固有の問題ではなく、 filename の内容だけに基づいて状態遷移を行う全ての実装に存在しうる問題です。この問題をどうするかは次期バージョンへの検討課題にしたいと思います。

ポリシーで明示的に alias を指定しないと機能しないというのは不便かもしれませんが、 argv[0] の内容を確認しないプログラムに適用するのは危険であるため、ポリシーで明示しない限りシンボリックリンクを解決するようになっています。
ただし、 argv[0] の内容を確認しないプログラムに対して alias 指定をすることを禁止するものではありません。例えば、 /usr/sbin/sendmail.sendmail へのシンボリックリンクである /usr/local/bin/sendmail.sendmail を作成して、 alias /usr/sbin/sendmail.sendmail /usr/local/bin/sendmail.sendmail と指定してやれば、 initializer /usr/sbin/sendmail.sendmail という指定がされていても /usr/local/bin/sendmail.sendmail を実行することで sendmail を呼び出し元ドメインの子ドメインとして実行させることができる（＝異なるアクセス許可を与えることができる）ようになるわけです。
なお、 alias /sbin/busybox /bin/ls のように指定されていても /bin/ls が /sbin/busybox へのシンボリックリンクになっていない限り alias 指定は効力を持たないので、「 /bin/ls が /sbin/busybox へのシンボリックリンク」であっても「 /bin/ls が /sbin/busybox のハードリンク」であっても「 /bin/ls が独立したプログラム」であっても大丈夫です。よって、頻繁に alias 指定を修正する破目にはならないと思います。

コンパイル済みのカーネルも用意してあります。 http://sourceforge.jp/projects/tomoyo/files/ からダウンロードできます。 TOMOYO Linux を試してみたいけどカーネルのコンパイルには手を出す勇気が無かったという方でも、現在では簡単に導入できるようになっています。
デフォルトのカーネルコンフィグファイルをベースに作成しているため Fedora Core 等の SELinux を有効にしているディストリビューション用のカーネルでは SELinux が有効になっており、 SELinux で動作中のＰＣでも使えるはずです。

sftp を使った安全なデータ転送システムの構築例

テクニカルエンジニア（情報セキュリティ）の午後�U試験では迷うことなく「問２」を選択した熊猫さくらです。
「問１」は見た瞬間に SELinux の MLS/MCS を連想してしまい拒絶反応を起こしてしまいました。（笑）
「問２」は TOMOYO Linux で守ってあげたいなぁと思いながら解答しました。

さてさて、前置きはこれくらいにして本題へ入りましょう。今回の目的は、「独自ＣＧＩを利用せずに既存のソフトウェアだけで同様のことを実現する」ことです。クライアントに新規ソフトを導入しないで済むことは利便性という面では重要ですが、危険なサイトへもスクリプトやクリック１つで飛ばされてしまうようなブラウザを使わないこともセキュリティという面では重要だと思います。なので、今回紹介する方法では、クライアントはブラウザを使わずに専用ソフトを導入してもらいます。

TOMOYO Linux はシステムレベルでユーザ単位のアクセス制御が必要な用途には向いていませんが、「利用者が少人数である」または「利用者の追加と削除が頻繁には発生しない」場合には、ディレクトリのパーミッションを 700 にすることで DAC によるユーザ単位のアクセス制御が可能になります。

以下、手順とポリシーの概要について説明します。ポリシーの種類は Targeted で構いません。（trust_domain /sbin/init と initializer /usr/sbin/sshd を指定することで sshd および sshd から実行されるプログラムだけを制御することができるようになります。）

必要な数だけユーザを作成します。ここでは、 user1 と user2 の２人を作成します。 データの置き場はホームディレクトリの下の data ディレクトリとします。当該ユーザ以外がアクセスできないようにするためにパーミッションは 700 にします。

useradd user1 su -c 'mkdir data; chmod 700 data' - user1 useradd user2 su -c 'mkdir data; chmod 700 data' - user2

ssh ログイン用の設定を行ってください。なお、 ssh でログインするための設定については他のサイトを探してください。

ユーザ側に適当な sftp クライアントソフトを導入してください。（実際には強制モードでの運用を開始してからユーザ側に導入するようにしてください。それまでは、ポリシーの策定作業を行う人の環境にだけ導入するようにしてください。）

これらのユーザには普通のシェルを与える必要が無いので sftp 専用のシェルを用意します。

echo '#! /bin/sh' > /bin/sftp-shell echo 'exec /usr/libexec/openssh/sftp-server' >> /bin/sftp-shell chmod 755 /bin/sftp-shell

/bin/sftp-shell をログインシェルとして使うように指定します。

usermod -s /bin/sftp-shell user1 usermod -s /bin/sftp-shell user2

ポリシーはこんな感じになるでしょう。（一部省略してあります。また、環境によって多少異なります。）

<kernel> /usr/sbin/sshd 1 /bin/sftp-shell 6 /dev/null 6 /dev/ptmx 6 /dev/pts/\$ 4 /etc/passwd 4 /etc/shadow 4 /etc/ssh/moduli 4 /etc/ssh/ssh_host_dsa_key 4 /etc/ssh/ssh_host_key 4 /etc/ssh/ssh_host_rsa_key 4 /etc/ssh/sshd_config <kernel> /usr/sbin/sshd /bin/sftp-shell 1 /usr/libexec/openssh/sftp-server <kernel> /usr/sbin/sshd /bin/sftp-shell /usr/libexec/openssh/sftp-server 4 /home/user\*/data/\*

sftp-server に対して /etc/passwd に一致するようなアクセス許可が含まれていないことに注意してください。もし、 /etc/passwd に一致するようなアクセス許可が含まれていた場合、クライアントが get /etc/passwd を実行することで漏洩してしまいます。その他のライブラリファイル（ /lib/libc.so.6 等）についてはダウンロードされてしまうことを防ぐことはできませんが、機密情報ではないので勘弁してください。

それから、ファイルの一覧を取得できてしまうという点も違っていますが、既存ソフトウェアをそのまま使うことを条件にしているのでやむをえないでしょう。（設定ファイルで ls の実行を禁止できたらいいのになぁ。）

ご意見や改善提案がありましたら、遠慮なくコメントやトラックバックしてください。

「セキュアOSに関する本音BOF」資料の補足について

http://www.selinux.gr.jp/documents/2006bof.html にある、「TOMOYO側の主張」についての解説です。

この資料は、「当日使用した資料(全体の流れ)」のＰ１７に書かれている「○○な新機能の開発が必要かもね」および「○○の強みはここです！」という部分に反応して作成しました。Ｐ１とＰ２がセキュリティ強化のために開発しなければいけないと思う部分、Ｐ３とＰ４が TOMOYO Linux の利点です。結局時間不足で使われないままになってしまったのでここで説明することにします。

多くの小規模なシステムではユーザ情報の管理にローカルファイルを利用していると思われるので、公開する必要の無い重要なファイルの内容が漏洩しやすくなっているのではないかという点についてＰ１では触れています。
例えば、 sftp-server で ls コマンドを実行すると /etc/passwd を参照しようとします。明示的に /etc/passwd を open() しなくてもユーザに関する情報にアクセスする処理を呼び出すことで /etc/passwd が参照されてしまう可能性があるわけです。
しかし、 sftp-server に対して /etc/passwd に対する読み込み権限を与えてしまうとクライアントが get /etc/passwd を実行することでダウンロードできるようになってしまいます。（実際には sftp-server は /etc/passwd を読み込めなくても動作できるようですので、 sftp-server に対して /etc/passwd に対する読み込み権限を与えないことで対処できます。）

そこで、 glibc に対して、ローカルホスト内で完結しているけれど /etc/passwd のように open() でアクセスできてしまう方法ではなくて UNIX ドメインソケットのように open() ではアクセスできない方法によりユーザに関する情報にアクセスするためのインタフェースを開発してほしいなぁと思ったわけです。
パス名を入力することができるアプリケーションはたくさんあります。そのため、重要なファイルへパス名を指定して直接的にアクセスできる方法は、ソケットなどを経由して対話的な処理を必要とするといった間接的にしかアクセスできない方式に比べて、漏洩が起こりやすいと思います。（ただし、ユーザに関する情報にアクセスするための関数は同じなので、バッファオーバーフローの中からその関数を呼び出されてしまえば TOMOYO Linux ではお手上げなのですが。）

Ｐ２では、アプリケーションの構造を見直すことでセキュリティを強化できるのではないかという点について触れています。
ディレクトリトラバーサルやバッファオーバーフローを使って任意のパス名を指定して読み出せるような脆弱性が存在していた場合、そのプロセスがパス名を使ってアクセスできる全ての資源が危険になります。 SSH サーバや HTTP サーバが使用する秘密鍵を格納したファイルも漏洩の危険に晒されるということです。
Apache の場合は、実際のクライアントからの処理を行うプロセスは一般ユーザ権限で動作しているので、ディレクトリトラバーサルが可能であったとしても鍵ファイルを open() することはできないようになっているようですが、秘密鍵ファイルの内容を展開したメモリ上の領域を読み出せるような脆弱性があれば結局漏洩してしまうでしょう。

セキュリティ強化 OS は、アクセスできる資源を制限することはできますが、秘密鍵へのアクセスを許可しているアプリケーションに対して任意のパス名を指定可能な脆弱性が存在していた場合やバッファオーバーフローが存在していた場合には、セキュリティ強化 OS を導入しても秘密鍵の漏洩を防げません。
そこで、 execve でメモリ空間を確実に分離して、秘密鍵ファイルの内容を別プログラムに持たせてみてはどうかと思ったわけです。
セキュリティ強化 OS を使えば、秘密鍵ファイルの内容を保持するプログラムの実行や通信を制限できるので、ハードウェアを使った分離に近いことを実現できると思います。

TOMOYO Linux 1.1.3 の機能について

version 1.1.3 では、シンボリックリンクのままドメインを定義できるようにする機能が導入されます。

TOMOYO Linux はｉノードではなくパス名で制御しているため、 busybox のようなプログラムにもハードリンクを作成することで対応できるようになっていました。しかし、 http://d.hatena.ne.jp/hshinji/20060520 によると、ハードリンクを維持できない環境もあるようです。

そこで、 execve() に渡されたパス名がシンボリックリンクであるかどうかをチェックして、シンボリックリンクの場合には「シンボリックリンクのパス名」と「シンボリックリンクを解決したパス名」の組み合わせにより遷移先ドメインを決定するようにします。（TOMOYO Linux では LSM を使っていないので、 execve() に渡された（シンボリックリンクを解決する前の）パス名を容易に知ることができるのです。）
例えば、 alias /sbin/busybox /bin/ls という指定がされており、 /bin/ls が /sbin/busybox へのシンボリックリンクになっている場合、 /bin/ls が実行された場合は /sbin/busybox ではなく /bin/ls が実行されたものとしてドメイン遷移が発生するようになります。

また、監査ログ機能もオプションになります。組み込み系だとログを保存するためのディスク領域を確保できない場合があると思うので、使われない機能はコンパイル時に除外できるようにします。

既に実装は済んでおり、これから動作テストに入ります。

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

公開されたのは今日ですが、日付は Linux Conference 2006 BOF のあった６／２になっています。

内容については既に書いたのでもう書きません。

発案・設計・実装・テストまで一人で行っているので、私がうっかりミスをしても誰も見つけることができません。
神経を集中させながら一日中画面と睨めっこしっぱなしです。
無理をしすぎて、先月下旬、右目が痛くなってしまいました。
今は極力睨めっこしないように注意していますが、いつまで私だけでやっていけるか心配です。

せっかくオープンソース化されているのだから、もっとたくさんの人たちに参加してほしいです。 特に、

• ソースコードの検証（排他制御が適切かどうか等）
• ｘ８６以外のＣＰＵを搭載したマシンや各種ディストリビューションでのコンパイルと動作確認

をしていただける方がいらっしゃると大変助かります。開発よりもテストの時間が長くなってきた現在では、１台のノートＰＣで１人で黙々とやっているのでは間に合わなくなりつつあります。

まずは、スナップショットを CVS に登録して誰でもコンパイルと動作確認ができるような環境を整えたいなぁ。ソースコードをアップロードするために決裁で何日も掛かってしまう以上、 SourceForge の CVS を有効活用できていないのです。（泣）

TOMOYO Linux 1.1.2 の機能について（続）

version 1.1.2 では、 http://kumaneko-sakura.sblo.jp/article/696859.html で紹介したプログラムの集約機能が搭載されるのに加えて、ドメインに対するアクセス許可の変更が直ちに反映されるようになります。

今までは、ドメインに対するアクセス許可を減らすためにはドメインを一度削除して作り直さなければなりませんでした。しかし、そのドメインが使っていたメモリ領域を全て無駄にしてしまうため、メモリの無駄遣いを防ぐために、ドメインを削除して作り直す回数を最小限に抑える必要がありました。
そのため、ポリシーエディタでは「システムポリシーの追加と削除」「例外ポリシーの追加と削除」「ドメインの削除」は直ちに反映されたのに対し、「ドメインに対するアクセス許可の追加と削除」だけは s を押して保存しない限り反映されないという中途半端な仕様になっていました。
その他にも、ポリシーエディタでの編集中に発生したカーネル内のポリシーの追加や削除が、ドメインを削除して作り直すことにより失われてしまう可能性がありました。

version 1.1.2 では、ドメインに対するアクセス許可を減らすためにドメインを削除して作り直す必要が無くなった為、無駄になるメモリの量が大幅に減少しました。そのため、ポリシーエディタでも「ドメインに対するアクセス許可の追加と削除」が直ちに反映されるように変更されました。

信頼済みドメインでポリシーエディタを実行しながら、学習モードで許可したい操作を行うことで、ポリシーの学習と編集を平行して行えるようになるため、ポリシー策定作業の効率が向上することを期待しています。

なお、一度割り当てられたメモリ領域は解放されないので、無意味な削除や追加は避ける必要があります。

それから、学習モードで自動的に追加されるアクセス許可の上限（MAX_ACCEPT_FILES）のデフォルト値を 256 から 2048 に変更しました。これは、最近のディストリビューションには非常にたくさんのファイルを読み書きするプログラムが含まれているので、 256 だと学習しきれないケースが増えてきたためです。（MAX_ACCEPT_FILES は、 find / -print0 | cpio -o0 -H newc のような無茶な操作を学習させた場合に、アクセス許可の追加処理によるレスポンスの極端な悪化とメモリの浪費を防止するための安全装置です。）
もちろん、プロファイルで指定すれば良いのですが、指定しない限り

TOMOYO-WARNING: Domain '<kernel> ...' has so many ACLs to hold. Stopped auto-append mode.

というメッセージが表示されるのが鬱陶しかったので、変更することにしました。

Re: 情報フロー分析再考：パス名ベースのセキュアOSの弱点とSELinuxの留意点

http://d.hatena.ne.jp/himainu/20060519#1148057602 に対するコメントです。長くなるのでこちらに書きます。

>「パス名ベースのセキュアOSで継続的にセキュリティを保つには、
>ハードリンクの生成を常に監視しつづけなければならない。」
「ラベルベースのセキュアOSにおいてはハードリンクを利用した攻撃に対しては抵抗力があるが、
複製物（ハードリンクを使わないコピー）や派生物（エディタなどで変更を加えたもの）に対する抵抗力は無い。
ラベルを使えばハードリンクを利用した攻撃を回避できるから情報フロー分析に基づく保証が可能という主張は間違いであると私は考える。」

> ラベルパス名ベースのセキュアOSで、パスワードに誰がアクセスできるか？を分析したいとする。
> * /etc/shadowのラベルにアクセスできるドメイン一覧を検索
> * 終わり。
というのは違うと思います。

/etc/shadow を含むデバイスファイル（例えば /dev/sda1）を読むことができるプログラムは /etc/shadow のラベルを持つファイルの内容にアクセスできます。
例えば、 /usr/sbin/smartd が該当します。
/usr/sbin/smartd（http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/fc3/domain_policy.txt?v=policy-sample#L2997）は /dev/hda を読み込みモードでオープン（#3000）し、 /bin/bash（#2999）を実行します。
/usr/sbin/smartd から起動された /bin/bash （#L3012）は /bin/mail （#L3014）を実行します。
/usr/sbin/smartd から起動された /bin/bash から起動された /bin/mail （#3026）は /usr/sbin/sendmail.sendmail （#3032）を実行します。
/usr/sbin/smartd から起動された /bin/bash から起動された /bin/mail から起動された /usr/sbin/sendmail.sendmail （#3038）は /var/spool/clientmqueue/ ディレクトリへ保存したり、他のホストへ送信することができます。
もし、 /usr/sbin/smartd と /usr/sbin/sendmail.sendmail がトロイの木馬であった場合、 /etc/shadow の内容を第３者に送信することもできてしまうでしょう。

あるプログラムが /etc/shadow を参照することができ、 /var/shadow というパス名に書き込むことが可能である場合、 /var/shadow に /etc/shadow と同じラベルが割り当てられることは期待できません。
cat /etc/shadow > /var/shadow
に相当する処理がポリシーにより許可されている場合、 /etc/shadow のラベルにアクセスできるドメイン一覧を検索したところでパスワード（のハッシュ）が漏洩することは防げません。 /etc/shadow へのアクセスを制限するのはパスワード（のハッシュ）が漏洩することを避けたいからであるのに、 /etc/shadow へアクセスできるプログラムは foo と bar だけだから大丈夫だと思い込むのは危険です。

/dev/sda と同様に、アーカイブファイルの場合も問題です。
find /etc/ -print0 | cpio -o0 -H newc > /tmp/etc.cpio
に相当する処理がポリシーにより許可されている場合、 /tmp/etc.cpio には /etc/passwd や /etc/shadow などの情報も含まれています。
１個のファイルには１個のラベルしか許されない以上、 /tmp/etc.cpio にはどのようなラベルを付ければ良いのでしょうか？

MLS/MCS のような場合も当てはまると考えます。公開ファイルと社外秘ファイルが組み合わさった場合、どのようなラベルを付ければよいのでしょうか？新しいファイルに社外秘ファイルの内容が含まれていることをコンピュータが知ることはできるのでしょうか？

> この話が成り立つには、
> パス名ベースのセキュアOSで、
> 「/etc/shadowに適切なラベル(タイプ）が割り当てられている」ことが大前提となる。
ラベルベースのセキュアOSで全ての資源に適切なラベル(タイプ）が割り当てられているという前提は成立しません。
情報の価値（割り当てるべきラベル）を決めることができるのは人間だけです。
人間がファイルの内容を考慮（＝１ビット単位で情報の価値を判断）して割り当てるべきラベルを決めなければなりません。
そして、人間の意識していない場所で利用されている一時ファイルにもファイルの内容を考慮して適切なラベルが割り当てられない限り、情報漏えいを防ぐことはできません。
そんなことはコンピュータにできることではないのです。

> * 結局、SELinuxでも「初期状態」構築時に、全ハードリンクを洗い出す必要がある。
> * パス名ベースは,「初期状態後」に弱味が。
> o 初期状態後に、/etc/shadowのハードリンクを作られたら、穴ができてしまう。
> o ★結論★これを防ぐには、常にハードリンクが作られてないか監視する必要がある

* ラベルベースにも「初期状態後」に弱点がある。
o 初期状態後に、 /etc/shadow の内容の（ハードリンクではない）コピーを作られたら、穴ができてしまう。
o ★結論★これを防ぐには、常に情報の価値に基づく適切なラベル付けが行われているか監視する必要がある。

> AppArmor, TOMOYO Linuxにはこの弱点が当てはまると思う(間違ってたら教えてください)
これはその通りです。でも、脅威はハードリンクだけでは無いのです。
TOMOYO Linux では、情報フロー分析に基づく保証は行えません。しかし、 SELinux でも情報フロー分析に基づく保証を行えるとは思っていません。

TOMOYO Linux 1.1.2 の機能について

version 1.1.2 では、プログラム名の集約機能が導入されます。

例えば、 http://kumaneko-sakura.sblo.jp/article/328948.html で述べたように Fedora Core 3 に含まれている logrotate パッケージは /tmp/logrotate.\?\?\?\?\?\? というパターンのプログラムファイルを動的に作成して実行するため、現状では /usr/sbin/logrotate を信頼済みドメインで実行する必要があります。
しかし、 /tmp/logrotate.xyz123 や /tmp/logrotate.Afz1g5 のようなプログラム名を例えば /tmp/logrotate.tmp というプログラム名に集約することで /usr/sbin/logrotate とそこから起動されるプログラムを強制アクセス制御が有効なドメインで実行させることができるようになります。
http://kumaneko-sakura.sblo.jp/article/328945.html で述べたお願いの内、「プログラムのパス名は固定するようにしてください」という制約が無くなります。

その他にも、 /usr/bin/tac と /bin/cat を /bin/cat という名前で集約したり、 cron と anacron を cron_job という名前で集約したりすることができるようになります。

既に実装は済んでいますが、これ以外にどのような機能が追加されるかは未定です。

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

公開されたのは５／１７ですが、日付は Open Source Revolution 講演のあった５／１５になっています。

今回のリリースの特徴は、パッケージのアップデートによって生じるパス名や依存関係の変化に対処するために「ポリシー違反が発生しても管理者の判断によりアクセスを許可することができる」機能と「共有ライブラリのパス名が変化した場合に自動的に反映する」機能が搭載されたことです。これにより、パッケージのアップデート作業がいくらか簡単になると思います。
使い方は http://tomoyo.sourceforge.jp/ja/1.6.x/update.html にあります。

今までも信頼済みドメインという指定が可能でしたが、マウント制限などのように SAKURA (Domain-Free Mandatory Access Control) support に含まれる機能は信頼済みドメインに対しても適用されていました。パッケージのアップデート時のみ必要なアクセス許可を学習させるのは大変だし、アップデート時のトラブルの原因になるから一時的に SAKURA を無効にしようかと思うこともありました。
今後は必要に応じて対話的に許可を与えることができるため、パッケージのアップデート時のみ必要なアクセス許可を学習させる必要はありません。
http://kumaneko-sakura.sblo.jp/article/293567.html や http://I-love.SAKURA.ne.jp/tomoyo/ に書きましたが、 SAKURA と TOMOYO はセットで利用すると効果的です。
SAKURA の設定は TOMOYO の設定と比べて簡単ですので、なるべく有効にしてあげてください。

version 1.1.2 へ向けてコードの修正を行っていた今日になって小さなバグを２点見つけました。実害は無いので次回リリース時に修正します。

TOMOYO (Domain-Based Mandatory Access Control) support を有効にして File Access Control support を無効にするという指定を行った場合、コンパイルエラーになります。ただし、 File Access Control support を有効にしないと TOMOYO を使う意味がありませんから、このような組み合わせで利用される方は居ないでしょう。

ccs_common.c で最大値を INT_MAX に変更するのを忘れていたため、 Default maximal count for grant log および Default maximal count for reject log で指定された件数までしか保持できないようになっています。通常はほぼリアルタイムに読み出されますから、これも問題にはならないでしょう。

TOMOYO Linux 1.1.1 の機能について

近日中に version 1.1.1 を公開予定です。

version 1.1.1 では、遅延強制モードが導入されました。

従来は、ポリシーに違反した場合、直ちにアクセス要求が拒否されるようになっていました。しかし、パッケージのアップデート時などにデーモンの再起動などを行うために /etc/init.d/ ディレクトリのスクリプトが実行される場合があります。現在の手順書では /etc/init.d/ ディレクトリのスクリプトを initializer に指定しており、信頼済みドメインから起動された場合でもスクリプトは信頼済みドメインの外部で実行されるため、学習が不十分だとデーモンの再起動などが失敗する可能性がありました。
そこで、ポリシーに違反しても直ちにアクセス要求を拒否するのではなく、管理者の判断によって例外的にアクセス要求を許可できる仕組みを導入しました。平常時は「ポリシーに違反した場合は直ちにアクセス要求を拒否する」設定で運用し、平常時には必要の無いアクセス許可が必要になる可能性がある作業を行う場合に限り「ポリシーに違反した場合は管理者の判断を仰ぐ」設定に変更します。
これにより、メンテナンス時の予期せぬアクセス要求に対して対処できるようになります。

ドメイン単位の強制アクセス制御だけでなく、システム全体での強制アクセス制御についても同様です。
パッケージのアップデート時にだけ必要になるマウントの組み合わせやカーネルモジュールの読み込み等もポリシーに全て学習させておくのは非常に面倒な作業であるため、現実解としては一時的に強制アクセス制御を無効化するという対処がありました。
しかし、一時的ではあっても強制アクセス制御を無効化することは侵入の隙を与えることになるため、望ましいことではありません。
version 1.1.1 では、マウント制限などを一時的に無効化しなくとも、要求が発生した時点で判断すれば対応できるようになります。

本当は子供の日である今日にあわせて version 1.1.1 を封印解除するつもりでしたが、上記の新機能が特許に抵触していないかどうかの確認作業を行う必要が生じたため、少々遅れることになりました。

「予め定められた方針とは異なる要求が発生した場合に、直ちにその要求を拒否するのではなく、管理者に要求の内容を提示して判断を仰ぐ」という動作は様々なアプリケーションで当たり前に使われています。
ファイアウォールで「○○というアプリケーションがポートＸＸ番へのアクセスを要求しています。許可しますか？『はい』『常に許可』『いいえ』」というポップアップを表示するのもそうですし、ファイルのコピーで「ファイル○○を上書きして良いですか？ Yes/All/No」というプロンプトを表示するのもそうです。もしこれが特許の問題に引っかかるようだったら、世の中のソフトはみんな引っかかることになっちゃうと思うんですがね。（＾ｘ＾；