himainuの日記

OMO 2006/09/08 08:53 だからFedoraは開発者向けDistroだと何万回も言われてて・・・:-p
まあ、安定サーバ作る人は、間違っても選んじゃいけないDistroですな。

intrajp 2006/09/08 11:03 そういえばdevelパッケージ私もインストールしましたよ。
segatexのyum install/updateボタンで。
ちなみに、うちの仕事場はMiracle(Asianux)が主体です。

忙し猫 2006/09/09 07:54 > 何のためにFC5ってあるんだろうと思う。
勿論RedHatのためでしょう。

> Fedoraはあくまで「開発者向け/Redhatの実験用」のdistroな気がする。
いや、最初っからそうだと思うのですが・・・。(^^;

himainu 2006/09/09 23:19 OMOさん
>まあ、安定サーバ作る人は、間違っても選んじゃいけないDistroですな。
Fedoraサーバー作ってる人は、どんなつもりで立てているのでしょうかね。
「技術の勉強用」ならば、大丈夫そうですが。。

intrajpさん
segatex,進化しまくってるようですね。私の周辺でも期待が高まっています。

忙し猫さん
>> Fedoraはあくまで「開発者向け/Redhatの実験用」のdistroな気がする。
>いや、最初っからそうだと思うのですが・・・。(^^;
そうですね。当初からそう発表されてましたから。。
「Fedora でサーバー構築」みたいな記事やら本を良く見かけますが、
罪深い（？）ですね。

KaiGai 2006/09/10 01:29 そーいや、某MixiはFedoraの4か5で運用されてるとか。カーネル読書会での話の又聞きだけど。大丈夫なのかな…。

yuyat 2006/09/10 01:48 自分もSELinuxのトレーニング用にはCentOSを使ってますよ。
FC5だと新機能すぎて使えないから、今すぐ使える安定版を教えてほしいという要望のほうが多い感じです。

某mixiがFCなのは聞いたことありますね。FCだけがドライバを認識したから採用したとか。

intrajp 2006/09/10 08:07 でも、来年になったらRedHatのバージョンが上がるからFC5のモジュール方式
に慣れていた方がいいのでは。私も話し相手が欲しいっす。不安定版を
みんなで使って直していくという発想ですから。ちょっと逸脱してるかな？

intrajp 2006/07/15 21:59 確かに色々と便利になってますよね。
でも、やっぱり一般ユーザはめんどくさくてそんなコマンド
打ったりしないですよね。
私もちょっと余裕が出たので、SELinuxモードになろうかなと思っていますが、
日本は暑くて、自分でやったこともすっかり忘れそうだし。
ちょこちょこプログラム（自作ツール？）という形で
まとめておくのもいいかもですね。
誰も使ってくれなくても、絶対、糧（かて）になっていると思います。
自分もSELinuxをやりだしてから、色々な問題にも
迅速的確に対処できるようになり、人間的にも成長したような
気がします、というか、ものすごい時間をつぎこんでいるんですから、
そう思わないとやっていられません。
ああ、なんか時期的に去年と状況が似てきたような気がする
ところで、OMOさんの妄想はどうなったのかな？
実験には、すごく注目してるんですけど。

himainu 2006/07/16 01:52 ＞でも、やっぱり一般ユーザはめんどくさくてそんなコマンド
＞打ったりしないですよね。
audit2allowもあと一歩という気がしています。

＞気がします、というか、ものすごい時間をつぎこんでいるんですから、
＞そう思わないとやっていられません。
費やした時間をカウントしたら、凄そうです。
＞ところで、OMOさんの妄想はどうなったのかな？
そういえば、反応できてないです。。

引越し関係が忙しすぎです。

intrajp 2006/07/04 06:28 >次回生成時は、ファイル名が違っている。
>永久にpukiwikiが動作するポリシを生成できない。
自分は、アプリケーションがインストールされるときを除いて、
できるだけファイル生成が少ない（ない）方が
SELinux的には（セキュリティ上は）いいアプリケーションだと思います。
そういった意味では、ファイルをどんどんつくっちゃうwikiはよくないかもです。
という問題意識で自分プロジェクトですが、
何でもデータベースに突っ込む考え方です。
表示するときは１つのファイルからしか表示させないようにすれば、
色々気を配る必要がなく、安全です。
おお、パス方式に対するアンチテーゼがもう一つできたぞ。
Danか誰かが言ってましたが、
「SELinuxはプログラムの不正を暴く！」っていいキャプションかもです。
言い過ぎか...。

himainu 2006/07/04 11:27 ファイル生成、削除は、ファイルタイプ遷移の設定やら、厄介ですからねぇ。
無いに越したことはないです。
＞何でもデータベースに突っ込む考え方です。
確かに、ポリシは間単になりますが、
ＤＢＭＳ自体の設定やら、SQLインジェクションやら、頑張る必要があるので、それも大変そうですね。

PANDA 2006/07/04 12:20 ＞ランダムな名前のファイルを生成している。
TOMOYO Linux の場合は file_pattern /var/www/pukiwiki/wiki/￥* のように指定しておけば
そのパターンを利用して自動生成してくれます。

＞1024より大きいポート番号をランダムに使おうとする。
TOMOYO Linux の場合はエディタを使って allow_bind TCP/1024-65535 という許可を追加します。

＞TOMOYO Linuxはどうしてるんだろ
何もしていませんよ。（笑）
それより、「enforcingモードにして、/etc/shadowが拒否されるようにしてやる」ことの必要性が不明です。
アクセスする必要があるからアクセスしているのに、それを禁止しても仕方が無いでしょう。
http://www.golden-gryphon.com/cgi-bin/archzoom.cgi/srivasta@debian.org--2005-selinux/pam--upstream--0.3--base-0/modules/pam_unix/support.c
http://www.redhat.com/archives/pam-list/2006-January/msg00027.html
http://www.nsa.gov/selinux/list-archive/0311/5818.cfm

himainu 2006/07/04 12:27 >TOMOYO Linux の場合は file_pattern /var/www/pukiwiki/wiki/￥* のように指定しておけばそのパターンを利用して自動生成してくれます。
>TOMOYO Linux の場合はエディタを使って allow_bind TCP/1024-65535 という許可を追加します。

釣られてくださり、ありがとうございます。参考になりました。
やはり、これについては「魔法」は存在しないのですね。

>アクセスする必要があるからアクセスしているのに、それを禁止しても仕方が無いでしょう。
言われてみると、最初からunix_chkpwd使うようにすればいいように思えます。謎ですねぇ。

PANDA 2006/07/04 12:44 ＞最初からunix_chkpwd使うようにすればいいように思えます。
unix_chkpwd は unix_chkpwd を実行したプロセスの uid を持つユーザについてしか認証しません。
ですから、 sshd のように uid = 0 のプロセスが unix_chkpwd を実行しても
uid = 0 のユーザの認証しかできないので他のユーザに切り替えてよいかどうか判断できないのです。

kai10 2006/07/05 15:35 selinux の勉強がてら、2.0.0-1を使ってみたのですが、’Domain/Role Manager’の’Create Domain’の’create template’で template を編集して Apply したときに表示されるウインドウに Window Manager の装飾が付きません。また、’seedit-load: Success’でも、ウインドウが消え去ることがありますね。ちなみに、template 編集カラムに行番号が出るとうれしいかも。
あと、seedit-gui-status のウィンドウで、ウインドウの大きさ(縦)を変えたときの余白が微妙です(うまく表現できず)。GTKがらみですかね。

himainu 2006/07/06 00:13 kai10さん、使ってくれてありがとうございます！

>Apply したときに表示されるウインドウに Window Manager の装飾が付きません。
これは、ウィンドウを閉じられると困るので、「x」ボタンを消そうとしたのですが、消す方法が分からなかったので、枠ごと消してしまってます。

>また、’seedit-load: Success’でも、ウインドウが消え去ることがありますね。
正常なふるまいです。成功の場合は自動的に消すようにしてます。
が、誤解を招かないために、自動的に消すのはやめたほうがいいかもしれませんね。

>ちなみに、template 編集カラムに行番号が出るとうれしいかも。
これは、なんとか入れてみたいです。

こうやってコメントもらってみると、
GUIの細かい部分は改善の余地が多々ありそうなことが分かります。
また、何かありましたら教えてください。

OMO 2006/05/23 09:49 情報フロー分析は、多いに興味があるところなんですが、
定量的にやる手法って確立されているんでしょうか？
#興味はあるけれど、情報を掴んでいないです(--;

himainu 2006/05/23 10:17 そう、SELinuxで誰もが納得いく情報フロー分析をした
実例は公開されてないはずです。
聞けば教えてくれるんだろうか。
「理論的に出来る」って彼らは思ってるのでしょうが、
実物見ないと信じられませんよねぇ。

himainu 2006/05/23 11:54 そういえば、
「情報フローに影響するカーネルの操作が
漏れなくSELinuxによって制限可能」ってことの保証もないですねぇ。

PANDA 2006/05/23 12:58 > 「情報フロー分析の必要性を明らかにしたい」、だけです。
> 特定のセキュアOSの欠点を見つけてSELinuxの優位性を主張したいわけじゃないです。
了解しました。意地悪な例を示してしまってごめんなさい。また、お忙しい中、回答を作成いただきましてありがとうございます。

> 「SELinuxは情報フローを保証できるプラットフォームを適用してない」
今回食って掛かったのは、「保証」という言葉を使うのが適当なのかどうかを問いたかったからです。
情報フロー分析の有用性・必要性についての議論なら構いません。
「パス名ではできないけれどラベルならできる」とラベル派は主張していますが、情報フロー分析の完全性について文句を言いたかったのです。
flow analysis をしたから完璧だと思っていたら、実際には flaw analysis になっていたというのでは困りますからね。

> が、部分的にでも情報フローを分析可能＆保証可能
> なシステムにも意義があるのかもしれません。
”部分的”には情報フローを分析可能＆保証可能だと思います。でも、単純に「保証」という表現を使ってしまうと、抜け道が存在しないように”全体”をカバーできているかのような錯覚を利用者に与えてしまいます。
私だけかもしれませんが、ラベル派の主張を聞いていると「ラベルベースであればこれこれこういう手順に従うことで完全に制御できる」という印象を受けてしまいます。

SELinux における「情報フロー分析に基づく保証」という意味は、

・SELinux で制御している箇所と SELinux のポリシーで制限できる範囲についてのみ適用されるものであり、システムの全範囲に適用されることを保証しているわけではない。

・初期状態においては保証するが、初期状態後においては保証していない。

というところでしょうか。
flow analysis ならば情報がどのように伝播していくかという「初期状態後」も扱うべきだと思います。それは、ポリシーファイルを閲覧するだけで瞬時に答えがでるような話ではなく、詰め将棋のように先々の状況まで検討しないと答えが出せないものなのだと思います。

PANDA 2006/05/03 10:18 > 卑怯な（笑 　たぶん、AppArmorでは困ると思う。
AppArmor で SuSE に対して strict なポリシーを適用するのは困難でしょうね。（笑）
起動スクリプトからシステム設定プログラムが実行される場合があるから、全てのパターンを把握しておくことは無理なので、 TOMOYO Linux では信頼済みドメインに置くようにしました。

TOMOYO Linux では file:getattr dir:getattr,read,search を無条件許可にしています。
守るべきはファイル名の存在ではなくファイルの内容だと考えているからです。
機密情報をファイルの中に保持することはあっても、機密情報をファイル名に保持させることは通常ありません。
> 全ファイル一覧が欲しいプログラム(updatedb, fixfilesなど)
だけでなく ls とかでも非常に不便です。
所詮、 /home/bob ディレクトリの存在から bob というユーザがいることが判明してしまうのを心配したところで、 /etc/passwd の参照を許可した時点で bob というユーザの存在を隠せなくなるのですから。

himainu 2006/05/03 23:25 >AppArmor で SuSE に対して strict なポリシーを適用するのは困難でしょうね。（笑）
そもそも、strictはやらない方針ですしね。

> TOMOYO Linux では file:getattr dir:getattr,read,search を無条件許可にしています。
私は、大学でやってるので、
これらを取り除くための学問的理由が必要で、困っているところです。
getattrはいらない気がしてて，
dir:read, searchは精神衛生上必要だと思うのですが、
論理的に言えない。。

>所詮、 /home/bob ディレクトリの存在から bob というユーザがいることが判明してしまうのを心配したところで、 /etc/passwd の参照を許可した時点で bob というユーザの存在を隠せなくなるのですから。
そう、それです！！
なにげに、ほとんどのサーバープログラムは、「/etc/passwd」を読むし、
SELinuxのstrictポリシーでも/etc/passwdは「passwd_t」なんですよ。
結局、dir:searchやらgetattrの意味がなくなるんですよ。

SELinuxは、最強を目指していて、AppArmorに「おまえのsecurity goalは何だ？？」てしつこく聞くわりに、Fedora添付のポリシのセキュリティに以外と無頓着なところがあるんですよねぇ。「カーネルの人間には関係ない」ってことかも。
SELinuxも、「多くの人に使われるシステム(LSPPじゃないシステム)におけるポリシー込みのSecurity goal」はよくわかりません。

PANDA 2006/05/04 10:05 公開鍵暗号を使うデーモンの秘密鍵を扱う処理部分だけ別ドメインで実行できると嬉しいですね。
現状、クライアントに渡す公開鍵とサーバ外に漏らしてはいけない秘密鍵とを同一ドメインでアクセスしてしまうため、バッファオーバーフローやディレクトリトラバーサル等で任意のパス名の指定が可能だと攻撃者が秘密鍵を読み出せてしまう可能性があります。
SELinux では対策済みなのかなぁ？

ところで、公開鍵暗号って安全性が高いって言われていますけど本当なんでしょうかね？
理論音痴・数学音痴の私には解りませんが、公開鍵から秘密鍵を計算により力ずくで見つけようとしなくても、鍵ペアの作成を力ずくで行えば意外と簡単に解読できそうな気がします。
だって、世界中の計算機で鍵ペアの作成をしているのだから、「おや？私の生成した鍵が○○の使っている鍵と同じだぞ？」なんていう状況が起きてもおかしくないと思っています。

himainu 2006/05/04 13:10 >SELinux では対策済みなのかなぁ？
そういえば、これも悩みでした。対策できてないですね。
Apacheでもそうでした。証明書の秘密鍵を盗まれてしまう気がします。

>ところで、公開鍵暗号って安全性が高いって言われていますけど本当なんでしょうかね？
私も暗号はさっぱり分かりませんが、
大学の研究者が好きそうな分野だし、
複数人が人生をかけてやっているはずなので、
単純な見落としは考えにくいです。
なので、たぶん大丈夫なんでしょう。
公開鍵がコンフリクトする確率も、きっと天文学的に低いんでしょう。

takaBSD 2006/05/05 16:30 > Kaigaiさんの和訳「条件変数」でいいような気がしてきた。
亀コメントですが、「ON/OFF変数」とか「スイッチ変数」ってどうでしょう。わかりやすいと思うのですが。
あと「ブールスイッチ」とか。

PANDA 2006/05/05 20:49 ピタゴラスイッチ（違）とか。
いや、あの番組のオープニングとエンディングで使われている仕掛けは良くできているなぁと感心させられます。

「○×変数」「真偽変数」「ＹｅｓＮｏ変数」あたりかなぁ。

himainu 2006/05/06 04:05 おっと、コメントが。色んな訳し方がありうるのですねぇ。
ありがとうございます。
「条件変数」がよさげだと思ったのは、
booleanが関わっている「Conditional Policy」機能をよく表しているなぁと思ったから、
っていうのもあります。