EuroBSDCon 2011レポート

はっきり見えてきたFreeBSD 10の行方

後藤 大地
2011/10/25

ケーパビリティを利用したアクセス制限機構

　ここからは、具体的に議論が進んでいる機能について紹介しよう。FreeBSD 9.0は、新しいセキュリティ対策機能「Capsicum（キャプシカム）」を導入する。初期状態では有効になっていないが、FreeBSD 9.1からは最初から有効になるようだ。既存の類似技術と比較してPOSIXとの親和性が高く、既存の実装にほとんど変更を加えることなく（数行追加する程度）サンドボックス化が可能という特徴がある。

　FreeBSDにはこれまで「保護ドメイン」と「アクセス制御リスト」の2種類のファイル保護機構が備わっていた。保護ドメインはいわゆるファイルパーミッションに相当する。「ファイルとそのファイルに対して許可する操作（読み、書き、実行）をユーザーに結び付ける」というもので、ファイルにアクセスする度にパーミッションをチェックすることでファイルを保護する。いわゆるchmod(1)で操作する内容が、FreeBSDの保護ドメインにおける保護の設定ということになる。

　アクセス制御リストは、「あるユーザーがそのファイルに対し許可される操作（読み、書き、実行）の集合を保持している」という保護機構。アクセスがあるたびにリストをチェックし、アクセスの可否を判断する。保護ドメインの実装も、アクセス制御リストの実装も細かい違いはあるが、ファイル側に許可情報を持たせ、アクセスした段階ではじめてチェックを入れるという仕組みだ。

　FreeBSD 9.0で新しく導入されるCapsicumは、ファイル保護機構の一種である「ケーパビリティ」の実装だ。ケーパビリティは保護ドメインやアクセス制御リストとは仕組みが大きく異なるので、最初は慣れないかもしれない。

　ケーパビリティの実装にはファイルディスクリプタを利用することが多く、Capsicumもそのような作りになっている。ファイルディスクリプタにファイルへのアクセス可否に関する情報を設定しておく。コマンドを使って保護設定をするというタイプの保護機構ではなく、C言語のソースコードレベルで活用できる保護機構だ。

　ファイルにアクセスする場合、ソフトウェアはファイルのディスクリプタを取得して操作する。この「ファイルディスクリプタ」にどの操作を許可するかを指定して新しく「ケーパビリティ」を作成し、以後はこの「ケーパビリティ」を経由してファイルにアクセスする（ここでの「ケーパビリティ」は保護機構名としての名前ではなく、特殊なファイルディスクリプタのことを指している。紛らわしいので注意が必要）。Capsicumではこのあと「ケーパビリティモード」へ移行する。「ケーパビリティモード」に入ると、「ケーパビリティ」以外を使ってのファイルへのアクセスができなくなる。

　従来の処理との違いを見てみよう。まず、これまでのコマンドは次のように動作する。

1. ファイルディスクリプタを取得する
2. ファイルにアクセスする

　Capsicumを使うと次のようになる。

1. ファイルディスクリプタを取得する
2. ファイルディスクリプタからケーパビリティを取得する
3. ケーパビリティモードに入る
4. ファイルにアクセスする

　一度ケーパビリティモードに入ったら、以後は二度とケーパビリティモードから抜け出せないというのが、Capsicumの最大の特徴だ。ケーパビリティモードに入ったら新しくファイルディスクリプタを取得することはできない。ファイルアクセスを開始する前に必要になるすべてのディスクリプタを取得しておく必要がある。プロセス自らがより積極的にリソースアクセスを制限し、隔離を進めることで、バグやセキュリティホールを突かれた場合でも外部リソースに与える影響を最小限に抑えることができる。

　Capsicumはいわばサンドボックス技術またはコンパートメント技術ともいえる。類似のサンドボックス／コンパートメント技術と比較した場合のCapsicumの最大の特徴は、POSIXとの親和性が高く、ソースコードを数行程度変更するだけで使える点にある。ほかの技術では数百から数千行の変更が必要になることもある。Google Chrome Webブラウザにおける実装例が最も分かりやすい。このあたりは論文に詳しくまとまっているので、詳細を知りたい方は「Computer Laboratory: Capsicum: practical capabilities for UNIX」をご覧いただきたい。

　DevSummit2011ではCapsicumそのものに関する議論はせず、具体的にどのコマンド、どのライブラリ、どのサードパーティツールに対してCapsicumを適用するのかということを検討していた。ソフトウェアにはCapsicumを適用しやすいものと、そうでないものがある。HASTdなどはすでにCapsicumを適用したコードを取り込んでいる。開発者はCapsicumのセキュリティ上の優位性を理解しており、FreeBSD 9.1以降、多くのライブラリやコマンドがCapsicumを適用することになるだろう。

　デフォルトでCapsicumをさまざまなライブラリやコマンドに適用したFreeBSDはセキュリティ対策で大きなアドバンテージを得ることになる。FreeBSD 10.0はその意味でエポックメーキングなリリースになるとみられる。

「パッケージセット」と「ウィークリーアップデート」

　FreeBSDの代表的なパッケージ管理システムとしては「Ports Collection」が挙げられる。アプリケーションやライブラリの更新が頻繁で、ビルド時にさまざまな加工が可能など、開発者や先進ユーザーにとって扱いやすいシステムだ。ブランチやバージョンといった概念を持たず、常に最新版というスタンスを取っている。

　Ports Collectionから特定のリリースや特定の状況に応じて提供されるバイナリパッケージ集は「Packages」と呼ぶ。Packagesはビルドの必要がなく、インストールするだけで済むので、初心者やライトユーザー、システムが安定して動作さえすれば良いという管理者や企業での利用に向いている。また、複数台のPCのアプリケーション管理などにも、Packagesが適している。

　しかし、Packagesは基本的に特定のリリースに対して提供されるPorts Collectionからのスナップショットと言えるもので、リリースのアップグレードに関してはあまり考慮されていない。このため、Packagesでソフトウェアのリリースをアップグレードしようとしてうまくいかず、歯がゆい思いをするユーザーは少なくない。

　そういう場合はPorts Collectionを使うというのが従来のやり方だが、これからはバイナリレベルでのアップグレードにも注力する方向に向かう。多くの一般ユーザーはバイナリレベルで簡単にアップグレードできることを望むためだ。

　これを実現するためにDevSummitで発表されたのは「パッケージセット」と、パッケージセットの「ウィークリーリリース」だ。「パッケージセット」はパッケージの集合によって構成される。この「パッケージセット」をウィークリーで（毎週）提供していく。パッケージセットごとにアップグレードを提供するようにして、より迅速で確実にソフトウェアをアップグレードできるようにしていくというわけだ。

　ウィークリービルドにはQA（Quality Assurance：品質保証）の側面を持たせるという意味合いもある。もちろん、セキュリティアップグレードが必要なアプリケーションやライブラリへの対応という役目もある。

　「パッケージセット」は3週間のみの提供となるため、常にアップデートしていく必要がある仕組みになっているところも注目だ。リリースごとに提供されるPackagesは、特定の時点における「パッケージセット」という位置付けになるが、リリースに対応したものだけは、従来通りのサポートポリシーの元で提供されることになる。

　「パッケージセット」と「ウィークリーリリース」が成功するかどうかは、ビルドクラスタの性能や実際にPorts committerがそこまでQA維持にリソースを割けるのか、大量のパッケージセットを世界中のサーバに迅速に配布できるのか、といった面も含めて今後トライ＆エラーを繰り返す必要がある。

　しかし、Ports committerの取り組みとしてこうした提案が出てきて、賛同する開発者がいることは注目に値する。FreeBSD 9系の後期やFreeBSD 10系ではバイナリ提供でのアプリケーションインストール・週一アップデートが日常化している可能性もある。

「EuroBSDCon 2011」の受付

2/3

Index EuroBSDCon 2011レポート 　はっきり見えてきたFreeBSD 10の行方

Page 1 　FreeBSD 10に向けて、いろいろ挙がる機能要求 Page 2 　ケーパビリティを利用したアクセス制限機構 　「パッケージセット」と「ウィークリーアップデート」 　 Page 3 　GPLフリーのツールチェーン実現への道 　各国からの参加状況

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）