Matthewの日記： ＴOMOYO Linux Ver. 1.4.1 & 2.0 Released 68
日記 by
Matthew
TOMOYO Linux Ver.1.4.1が6月5日に、Ver.2.0が6月7日にリリースされました。TOMOYO Linux といえばファイルやデバイスなどの強制アクセス制御などが行えるカーネルパッチとユーティリティですが、1.4.1は1.4のバグの修正や機能拡張が行われています。一方、2.0はSELinuxやAppArmorで利用されているLinux 2.6系カーネル標準のLSMフックを利用して実装されました(LSMは去年の今頃存亡の危機がありましたが)。いまのところ2.0の機能はファイル強制アクセス制御しか実装されていませんが、今後は2.0系がメインストリームになるそうです。詳しくはTOMOYO Linux プロジェクトサイトなどで確認できます。
既にカーネル読書会や専門雑誌などでの露出はありますが、開発サイトのWikiによると世界でまだ６人しか使っていないそうです。殆どのディストリビューション用にバイナリパッケージも用意されているので容易に試すことができます。興味を持った諸氏はTOMOYO Linuxのサイトを覗いてセキュアOSに挑戦しては如何でしょうか。
6人 (スコア:2, おもしろおかしい)
だから俺は使わないでおく。
Re:6人 (スコア:1, おもしろおかしい)
# 俺じゃないことは確かだ
Re:6人 (スコア:0)
Re:6人 (スコア:1)
プロジェクトはSourceForge.jpを利用させてもらっているので、ダウンロード数ならデータが参照できます。ダウンロード数はそのまま利用者数にはなりませんが、参考にはなるでしょう。
実際に利用している人数は、6人よりは多いでしょうけれども（笑）、数千人、数万人いるとは思っていません。「使う」は、「知る」ことから始まり、それがさらに「興味を持つ」にならなければ「使う」には至りません。TOMOYO Linuxは国内では多少知られるようになりましたが、まだまだ名前が先行していますし、本来TOMOYO Linux（を含めたセキュアOS）を使うことを検討すべき人たちの間で、セキュアOSが理解されているかというとそちらもまだこれからなのかなと思います。ある意味セキュアOSを使わないですむというのは平和な状態ですが、今後はWindows OSでアンチウィルスを使うのが常識になっているように、使いたくなくても使わなければならなくなると予想しています。
「少人数のために尽力している」というよりは、「それが必要であり役に立つ」ことを確信していると言ったほうが私の場合近いです。セキュアOSに取り組んでいる人は程度の差はあっても同様と思います。
tsh
Re:6人 (スコア:0)
とりあえず言っとくか (スコア:1)
名前変えたら? (スコア:1, すばらしい洞察)
Re:名前変えたら? (スコア:2, おもしろおかしい)
まさに目糞鼻クソ。
Re:名前変えたら? (スコア:1)
名前の由来って「HARADA TOMOYO」の方じゃないの？
# 時の流れって残酷ですね・・・
Re:名前変えたら? (スコア:1)
名前の由来はFAQに入れてあります。
tsh
Re:名前変えたら? (スコア:1, おもしろおかしい)
Re:名前変えたら? (スコア:1, すばらしい洞察)
Re:名前変えたら? (スコア:1, おもしろおかしい)
Re:名前変えたら? (スコア:1, 興味深い)
何が出来る物なのか的確にわかる名前じゃないと普及はしないね。
Re:名前変えたら? (スコア:1, おもしろおかしい)
Re:名前変えたら? (スコア:0)
禿胴
Re:名前変えたら? (スコア:1)
#私にはよくわかりませんが。
Re:名前変えたら? (スコア:0)
http://itpro.nikkeibp.co.jp/article/NEWS/20051111/224444/ [nikkeibp.co.jp]
これ入れるとSELinuxはいらなくなるのかしら？ (スコア:1)
この状態でネットワークを使ったサービスが動かすことができているなら、他にアクセス制御入れる必要性はあんまりないように思う。
なんかわからないけどSELinux使うとアクセスできなくなるから切っておけ～ という人にはSELinuxより簡単に同じ効果が得られるソフトはほしいと思う。
恥ずかしながら自分は後者なのだけれど、そこんとこどうなんだろう？
Re:これ入れるとSELinuxはいらなくなるのかしら？ (スコア:5, 興味深い)
以下のリンクは、lkmlでKyleという方が私のメッセージに返信してくれたものです。
Kyle氏が書いているように、SELinuxの開発サイドの基本的なスタンスは、「ポリシーはプロが書いて提供する」というものです。私は最初その考え方に抵抗がありましたが、色々やりとりをしながら次第にその考えに納得できるようになりました。それぞれのモジュール（パッケージ）を熟知したエキスパートが、対応するSELinuxの設定（ポリシー）を作成し、それが提供されていれば、ユーザはポリシーのことを気にせずに安心してシステムを使えるわけです。そうした考え方からは、「ユーザはポリシーを書くな」「ポリシーは（ソースでなく）バイナリで配布する」という発言も理解できます。実はKyle氏が言っているのと同じことを、SELinuxの開発者の一人であるRussell Coker氏が来日した際にも言われています。
ただ、現実の話としてSELinuxのポリシーはまだ完成しておらず発展途上です。また、「プロ」の集団がポリシーを作成するといってもその範囲には限りがあります。組み込み系で利用するユーザや個人でLinuxを使っているユーザはどうすれば良いでしょうか？
TOMOYO Linuxで作成するポリシーは彼らに言わせれば「アマチュア」のポリシーになります。それは否定しません。しかし、内容を理解したプロが書くというアプローチ以外に、計測を繰り返し到達するというアプローチも存在するはずです。Kyle氏に反論はしませんでしたが、「中身を理解していなくても正しいポリシーには到達が可能」と私は思っています。また、ハードウェア自体のカスタマイズも行う組み込み系の分野では、標準のLinuxのプロ以上に内容に精通しており、そうであればプロ以上のポリシーも書けると思うのです。
上記の内容をお読みになりご興味を持たれましたら、是非一度TOMOYO Linuxをお試しになってみませんか？お待ちしています。
tsh
Re:これ入れるとSELinuxはいらなくなるのかしら？ (スコア:1)
「中身を理解していない」で「到達」と仰るところには違和感があります。
「到達」したか否かの判断を、「中身を理解していなくても」できるとお考えなのでしょうか？
TOMOYO Linux は存知ませんが、SELinux のポリシーはやはり難解だと思っています。プロが作ったものを受け取るだけで利用者は中身を知る必要がないという考え方に釈然としない部分が無い訳ではないですが、そこに適度な透明性があり、ポリシーの妥当性を監査、検証できる第三者が居さえすれば、問題視することではないと思えます。
はその通りだと思うのですが、ここで言う計測をエキスパートがやらずにアマチュアである利用者が行うということになると、折角苦労して作成した強制アクセス制御の機構が有効に機能できないことになってしまわないかと危惧してしまいます。
これらはポリシーの粒度や、強制アクセス制御機構そのものの柔軟性などに依存するだと思いますので、見当外れの意見かもしれません。
Re:これ入れるとSELinuxはいらなくなるのかしら？ (スコア:1)
Juliさん、
コメントありがとうございました。
> 「中身を理解していない」で「到達」と仰るところには違和感があります。
> 「到達」したか否かの判断を、「中身を理解していなくても」できるとお考えなのでしょうか？
自分の書いたものを読み直してみましたが、言葉足らずでした。まず使っている言葉について補足します。ここでいう「中身」はそれぞれのソフトウェア（パッケージ）の動作詳細を意味します。私は、Kyle氏やRussellが言うプロのポリシーとは、ApacheならApacheの開発者かそれに準じるレベルで動作を理解する者がポリシーを書く（書ける）という意味だと理解しています。次に「到達」ですが、「到達する状態」とは、必要なものが許可されて不必要なものは許可されないというポリシーです。
このような言葉の定義のもとで、私はあるソフトウェア（パッケージ）について、その開発者でなくても、あるいはそのソースコードを完全に掌握していなくても、それを用途に応じて動作させるためのポリシーを得ることが可能だと思っています。それを行えるかというのは要するに、動作を網羅した試験を行えるかということです（勿論、特定の状況（OSおよび他のパッケージのバージョン、それらの設定、コンテンツ等）が定められているというのは前提です）。
> そこに適度な透明性があり、ポリシーの妥当性を監査、検証できる第三者が居さえすれば、
> 問題視することではないと思えます。
逆に質問します。ここで書かれている「透明性」とは何ですか？バイナリで配布されるモジュールのポリシーについて、ユーザができることはそれを「信じる」しかない気がします。妥当性も同様です。そう考えると、結局SELinux陣営の言っていることは、「俺たちを信じろ」ということではないかと私は思っています。で、今まではあまり信じられないし信じたくないと思っていたのですが、少なくともKyle氏の作成したポリシーは信じられると思いました。ところで、「問題視することではない」と書かれていますが、私は「問題視していません」のでその点誤解なきようにお願いします。ただ、誰かが作ったポリシーを信じる以外に、自分で試行錯誤するのもありでしょ？と思っているだけです。それだけにすべきとは思いません。
> ここで言う計測をエキスパートがやらずにアマチュアである利用者が行うと
> いうことになると、折角苦労して作成した強制アクセス制御の機構が有効に
> 機能できないことになってしまわないかと危惧してしまいます。
言われている観点は理解できるのですが、網羅的な試験はソフトウェアの作成者でなくても行えるわけです。あなたが、Apacheのサーバを立てたとして、httpデーモン（のドメイン）を自動学習モードで動かせば、pngひとつから全てのコンテンツへのアクセスとドメインの遷移を忠実に洗い出すことができます。それはApacheのエキスパートが行う必要はなく、コンテンツの作成者である必要もないでしょう。逆に、SELinuxで配布されるApacheのポリシーは、一種平均的かつ特定の設定を想定したもので丸められたものになります。
以上ですが、ここで書いたことは一度実際にTOMOYO Linuxを使ってポリシーの自動学習を行っていただくとよく理解いただけるかもしれません。
tsh
Re:これ入れるとSELinuxはいらなくなるのかしら？ (スコア:1)
すみません、時間がないのでちょっと明確な応答になるか判らないのですが…
言葉の定義についてですが、「中身」、「プロのポリシー」、「到達する状態」の何れとも、多分、定義して頂いた様な意味で使われているのだろうな、とは思っていました。ただ、私の方では、定義して頂いた内容に更に、セキュリティの概念を含んでしまっている様です。
私はセキュリティ関連について門外漢なので、そこもブラックボックスになってしまいます。そして、私が書いた「利用者」とは、その様な人々を表しています。
その結果として、
に関して言えば、ソフトウェアの動作そのものだけでなく、それを利用するに当たって必要な「セキュアな振る舞い」についても妥当な判断をしなければならないと捉えています。
で、多分、私が誤解してしまっている部分がある様に思いました。先のコメントで、
と仰っているのは、(Apache などの) ソフトウェアのプロではないけれども、セキュリティに関してはプロである「アマチュア」（つまり TOMOYO Linux の開発に関係しておられる方々）を指しておられるのでしょうか？
ここの「アマチュア」を、私の様な一利用者と捉えてしまったところに問題があった様に思います。
「適度な透明性」と書いたのは、実はバイナリ *のみ* の配布に条件を付けることを指しています。こちらこそ言葉足らずですみません。
一般の利用者にとってはバイナリしか見えないけれども、例えば、SELinux 開発コミュニティ以外のセキュリティに関する有識者に対し、ポリシーの内容が公開されている、というような状況を想定しています。暗号化アルゴリズムは完全に公開されているものがあるので、そのまま例としては不適当かもしれませんが、一般の利用者がアルゴリズム自体を理解せずに利用していて、有識者には様々な形で検証されている、という状況だけを考えて貰うとイメージし易いかもしれません。
セキュアな観点までも網羅した試験は一般の利用者には難しいと考えている訳なのですが、これは現状でも同じなのは承知しています。
サーバを管理するのであれば、セキュリティに関連するスキルを保有していて然るべきというのが現状でしょう。
ただ、将来的にはその様な観点でもハードルが下げられるようになると、よりセキュア OS の普及率も上がるのでは、という期待を持っています。
;; すみません、本当に時間が無くて書きっぱなしになってしまいました。判り難くて申し訳ないです。
Re:これ入れるとSELinuxはいらなくなるのかしら？ (スコア:1)
SELinuxであれTOMOYO Linuxであれ、セキュリティを強化したLinux=強制アクセス制御を導入したLinuxが目指しているのは結局、「不適切なシステムコールの実行を、必要なシステムコールの実行を妨げずにいかにはじくか」になります。個々のシステムコールの処理内容自体にバグがあればそれに対しては効力を持ちませんし、意味的にセキュリティに関する脅威を理解したり対処するわけではありません。ただ、この「不適切」を切り分けて、「適切」を残しながらはじくのが難しいわけです。
はじく範囲をうすくすれば「適切」を損なうリスクは減り、SELinuxのtargetedはそれに分類されるでしょう。実際、targetedだと、大半の人はそれが有効になっていても気づかない（困らない）わけです。strictは細かくなる分、不具合が発生します。でも、そもそもあらゆるシステムに共通で使えるということは、それだけ粗いわけです。それは既製服で自分に近いサイズを選ぶようなものです。それに対して、TOMOYO Linuxは実際の環境で測定してポリシーを作り上げます。オーダーメイドです。strictとtargetedの2種類が、モジュールの概念を導入してReference Policyとなりましたが、それは標準的な構成と設定のもとの組み合わせであり、利用する一人一人の環境に関係なく作られたものです。それに対してTOMOYO Linuxは「その人の環境」でポリシーを測定（実測）し作成します。基本的な考え方が違うのです。だからTOMOYO Linuxでは標準（デフォルト）のポリシーがありません。
「プロ」と「アマチュア」ですが、TOMOYO Linuxでポリシーを作る人は、無論セキュリティに詳しい人であれば望ましいですが、単純に必要なシステムコールをトレースするだけであれば、システムを知る人＝全ての機能を実行させる術がわかる人であれば良いです。その場合、全てのプロセス実行(execve)は異なるドメインとなり、ひとつひとつのファイルへのアクセスが区別され学習されます。「べた」なポリシーです。ただ、ドメイン遷移を統合したり、ファイルのパターンをまとめたりすることによって、ポリシーはより小さく、見やすくなります（この作業をチューニングと呼んでいます）。それについては、ある程度Linuxに熟練している必要があるかもしれません。
ということで、Juliさんが言われているところの「セキュリティ」については勿論重要だと思っていますが、こと強制アクセス制御（ポリシーの設定）という観点からはそれほど関係はタイトではないように思います。少なくともTOMOYO Linuxを使う上で必須ではありません。
tsh
Re:これ入れるとSELinuxはいらなくなるのかしら？ (スコア:1)
もう反応して頂けないかもしれませんが。
仰ることは大枠では理解してきたと思うのですが、個人的にはどうしても、
の部分には、セキュリティ要件が絡む様に読めてしまうのです。
そのため、
とは思えない、というところなのです、しつこいですね……すみません。
また、システムコール単位での切り分けが開発者でなくても可能という考え方は、完全性という面では厳しそうな感覚もあります。ただ、これは、リソースへのアクセスに限定して考えるという側面では、十分許容できる範囲なのでしょうね。
仰る通り、「先ずは使ってみろ、話はそれからだ」という事なのでしょう。
何れ利用させて頂きたいと思います。
Re:これ入れるとSELinuxはいらなくなるのかしら？ (スコア:1)
> 随分と時間が空いてしまいました、すみません。
> もう反応して頂けないかもしれませんが。
そんなことはありません。:-)
> 仰ることは大枠では理解してきたと思うのですが、個人的にはどうしても、
> 不適切なシステムコールの実行を、必要なシステムコールの実行を
> 妨げずにいかにはじくか「不適切」を切り分けて、「適切」を残しながら
> はじくのが難しいの部分には、セキュリティ要件が絡む様に読めてしまうのです。
> そのため、
>> こと強制アクセス制御（ポリシーの設定）という観点からはそれほど
>> 関係はタイトではないように思います。
> とは思えない、というところなのです、しつこいですね……すみません。
いえ、こうしたやりとりを通じて自分自身の考えを整理できますし、
何より意見を聞かせていただけるのはとてもありがたいです。
感謝しています。
内容についてですが、ではこう言い直したらいかがでしょうか？
「システムの挙動をトレースするのには、必ずしも
セキュリティの知識は前提とはならない」
実際、TOMOYO Linuxで行うのは、「実施した内容を実現する上で
生じたシステムコール（全てではありません）をトレース」
しているわけであって、それを保存、編集してから「強制」すると
強制アクセス制御になるだけです。「強制」するかどうかは
使い方次第ですが、それこそ強制されるものではありません。:-)
> また、システムコール単位での切り分けが開発者でなくても可能と
> いう考え方は、完全性という面では厳しそうな感覚もあります。
> ただ、これは、リソースへのアクセスに限定して考えるという側面では、
> 十分許容できる範囲なのでしょうね。
ここについては意見は書けるのですが、主観になってしまいます。
可能であれば実際にTOMOYO Linuxでご体験いただけると
良いかと思います。TOMOYO Linuxの機能は同じでも、それを
利用する人、利用する内容によっては異なる解釈があるかもしれません。
>> ここで書いたことは一度実際にTOMOYO Linuxを使ってポリシーの自動学習を
>> 行っていただくとよく理解いただけるかもしれません。
> 仰る通り、「先ずは使ってみろ、話はそれからだ」という事なのでしょう。
> 何れ利用させて頂きたいと思います。
「まず使ってみて下さい」というのは、説明を放棄しているようで
普段はあまり言わないのですが、TOMOYO Linuxの場合は、これまで他で
見たことがないようなものなので、言葉で説明するよりも
体験いただくのが正確ですし、早いです。バイナリパッケージを用意しており、
http://osdn.jp/projects/tomoyo/files/ [osdn.jp]
15分もあれば「自動学習」とは何かを「juliさんご自身の環境で」
確かめていただくことができます。TOMOYO Linuxを使うか使わないかに
かかわらず、表示される内容はJuliさんにとって参考になると
思うのでお勧めしている次第です。
tsh
Re:これ入れるとSELinuxはいらなくなるのかしら？ (スコア:1)
最新のFedora7ではどうか知らないけど。
# そろそろ7入れようかなぁ
1を聞いて0を知れ!
Re:これ入れるとSELinuxはいらなくなるのかしら？ (スコア:1)
FC6では、EnforcingをPermissiveに変更でした。。
1を聞いて0を知れ!
Re:これ入れるとSELinuxはいらなくなるのかしら？ (スコア:2, 興味深い)
SELinuxのポリシで許可されていない行為(いわゆるポリシ外のアクセス行為)が
発生してもアラートを表示するだけで禁止しませんので、実質SELinuxを無効にした
状態と「ほとんど」同じになります。なのでSELinuxがうるさくなくなったと言うよりは、
アクセス制御を全然やっていない状態に等しくなります。
内部的にはLinux起動時にLSMでの飛ばし先を全てdummyにした後に、
selinuxに引き渡しているので、Disabledとは全然違いますが
(なので、あくまでも「ほとんど」同じ)。
Kazuki Omo "You can subdue, but never tame me..."
Re:これ入れるとSELinuxはいらなくなるのかしら？ (スコア:1)
1を聞いて0を知れ!
Re:これ入れるとSELinuxはいらなくなるのかしら？ (スコア:1)
Targetedでも十分うるさいけど、Permissiveじゃ意味ないじゃん。
RHEL/CentOSの5とかだと、禁止動作のログを捕まえて、setsebootでそのサービスに対するアクセス制御を無効化しろ、とか言ってきますね。
lkmlにRFCを投稿しました (スコア:1)
tsh
Re:lkmlにRFCを投稿しました (スコア:1)
SourceForge.jpのニュースに日本語訳をつけて登録しました。
tsh
ファイルやデバイスなどの強制アクセス制御 (スコア:0)
何を意味しているのか不明瞭なので手を出す気にならないというか。
#「普通ならアクセスできないようなファイルやデバイスを強制的に制御できる」ってこと？
Re:ファイルやデバイスなどの強制アクセス制御 (スコア:5, 参考になる)
従来のパーミッションではログインしたユーザが、自身の所有するファイルをいい加減なパーミッションのままほったらかしにしていたり、ユーザが意図せず悪意あるプロセスを実行してしまった場合、それがセキリティ上の問題に直結する可能性がありました。
そこで強制アクセス制御ではシステム管理者が「セキリティポリシー」を定め、ユーザがそれに反するアクセス権を、たとえそのファイルの所有者がそのユーザ自身であっても適用することが出来ないようにします。
しかしこのセキリティポリシーは様々な条件に対してアクセス権限を指定出来る必要があり、Linuxの強制アクセス制御モジュールとして有名なSELinuxではセキリティポリシーの設定が複雑極まりないものであることが悩みのタネのようです。
# とかいいつつ使ってないので間違いとかあったら指摘よろしく
Re:ファイルやデバイスなどの強制アクセス制御 (スコア:5, 参考になる)
> 強制アクセス制御とは従来の任意アクセス制御(要するにパーミッション)に輪をかける形で権限を制限する機能のことです。
ここはちょっと微妙に違っていまして、アクセス制御の種類には
・強制アクセス制御(MAC)
・任意アクセス制御(DAC)
の二つの種類があると言う事です。理論上は、OSにMACだけの実装と言うのもありなわけですが、
一般的にはDAC+MACという実装方法がよくとられているので、Linux上ではDAC+MACという
形になっています。
あと、これはMACとかというよりはLinuxでのアクセス制御の実装方式(LSM)の話ですが、
Systemcall -> Linux Permission ->
security_XXX関数->SELinux or TOMOYO or AppArmor or LIDS or something...
みたいなチェック方式を取っていますので、最初にDAC部分がチェックされ、その後にLSMで
実装されているアクセス制御に基づくチェックが行われています。なので、
「DACにMACが覆いかぶさるような形」に見えます。2.4.X用のLIDSではMACチェック->DACチェック
の順で実装されていますので、MACで先にアクセスがはねられますので、覆いかぶさるような形
とはちょっと違います。
#横道にそれますが、LSMでDACを実装するというのもアリといえばアリです(uid=0なら絶対に1を返す、
#とか)。ただ、LSMで引き渡されている関数は、ほとんどの場合MACの実装(SELinuxとか)になっていると
#言う事です。
もちろん、既存のDACでのアクセス制御よりもシステムコール内に埋め込まれている数が
すごく多くなっていますので(無い物もあって、それが問題)、LSMでアクセス制御を実装した場合には
一般的なLinuxのアクセス制御よりも細かいレベルでアクセス制御を行う事が出来ます。
参考までに、2.6.20カーネルで、各システムコールでどの程度security_XX関数が呼ばれているかを
表にしてまとめて公開してあります。
http://www.selinux.gr.jp/LIDS-JP/systemcalls.html
Kazuki Omo "You can subdue, but never tame me..."
Ｔが大文字 (スコア:0)
Re:Ｔが大文字 (スコア:1)
ええ、もちろんしってますとも。
FULLWIDTH LATIN CAPITAL LETTER T (U+FF34)といいたいんですよね。
僕も気になりました。
Re:Ｔが大文字 (スコア:1)
コメントを読んで「?」と思って Firefox 上で確認しても分からなくて、w3m で見てやっと気づいたという。
Re:Ｔが大文字 (スコア:1)
Re:Ｔが大文字 (スコア:0)
Re:Ｔが大文字 (スコア:0)
Windows XP+Firefox 2.0で見てますが全然違和感がないですね。 気づきませんでした。
IE6だと、なんか変だな、というレベル。
w3mなら、気づかないほうがおかしい。
＃実はスルー力のないw3m使いを釣るための罠だったりして。
Re:Ｔが大文字 (スコア:0)
今試されるもの (スコア:0)
7本目になる勇気
世界で５人ぐらいいそうだ (スコア:0)
TOMOYO Windows (スコア:0)
Linuxなら自分でなんとかできるが、Windowsはぜんぜんわからんちん。
Re:LinuxはOSではなくて全てゴミ (スコア:2, おもしろおかしい)
# わざわざネットでそれを表明する行為こそがゴミだとは思うけどねぇ。
# そういえばどっかで「ACの書き込みはコメントではなくゴミ」ってのがあったなぁ。
# こういうのを見ると至言だと思いますねぇ。
# もちろんACでも貴重な指摘や発言もあるわけですが。
# と、ここまで書いて己のスルー力不足に orz
Re:ポリシ設定以外の管理コストは？ (スコア:2, 参考になる)
そんなあなたのためにEclipse GUIを開発中です。近日リリースできると思います。:-)
tsh
Re:ポリシ設定以外の管理コストは？ (スコア:1)
tsh
Re:ポリシ設定以外の管理コストは？ (スコア:1)
話をSELinuxに絞っちゃいますが、Tresys Technologyが出しています。
#OSSじゃないってところがネックなんですけれどね。
Tresys TechnologyはReference Policyを作ったところで、多くのSELinux技術者が
在籍しています。SELinuxを開発するために作られた会社ってイメージです。
Tresys Brickwall suiteのEnterprise Editionで、networkを通じてポリシの集中管理が
できるようになっています(RHEL4にReference Policyを入れ、それを配布／管理しています)。
http://www.tresys.com/products/brickwall-enterprise.html
Kazuki Omo "You can subdue, but never tame me..."