早間義博
yossi****@yedo*****
2011年 5月 26日 (木) 01:05:23 JST
早間です。 ありがとうございます。 > > そのため、ポリシーの内容はサポートされている構文で有効な設定であるという前提を > 置き、全体の書き込みが終わってから、正しく書き込まれたかどうかを確認したい > 場合には読み出して比較してもらうという流れにしています。 > > −−−−−−−−−−−−−−−−−−−− > tomoyo-editpolicy での追加するとき、追加が表示されているラインの最 下行より上の行に挿入される場合は表示に変化が現れるので判りますが、 追加が表示されているラインの最下行よりさらに下に行われると表示上何 も変化がありません。 正しく書き込まれた場合は追加した行を表示されている中に入るように スクロールするということには賛同者は出ないでしょうか。 > > # 「ネットフォース」のように敵対するオペレータに物理的被害を与える > > # ことが夢の一つです。 > > TOMOYO は戦争とは無縁な世界から生まれたセキュリティ > （ http://hp.vector.co.jp/authors/VA022513/guchi.html#88 ）ですので、 > 反撃するような機能は備えていません。 > > あ、でも、ＳＳＨブルートフォース攻撃で侵入してきた相手に対して精神的ダメージを > 与えること（ http://tomoyo.sourceforge.jp/2.3/chapter-10.html ）なら > できますよ。（笑） > > −−−−−−−−−−−−−−−−−−−− > ログインにかかる表示も今は、文字の羅列だけですが、いずれ視覚的・音響的 情報が送られるようになることでしょう。 Persona non grata と判断出来た場合には「吠えメール」をサービス出来 るかもしれません。 (.... /guchi.html#88 )私は、カードキャプタさくらのvideoを恐らくす べて見ていると思います。さくらファンの家人は TOMOYO-linux の情報が ネットに流れるとすぐに教えてくれました。その話によると「開発者の某 さんは当該アニメーションのファンである」と云うのが(故に家人の知る ところとなったのでしょうが)付いていました。TOMOYO が主人公でなく何 事にも動じないデザイナーであるのも興味深いものでした。すべてさくら の活躍をvideoに収め、時として「さくらちゃんの活躍を記録できなかっ たのは .. 」などと言う台詞はとても興味深いものです。 コンピュータがしかるべきアバタをもって話しかけてくることも実現され るでしょう。アバタにともよを使うと著作権で叱られるかもしれません。 20世紀中のことですが、NTTデータの音声ボードを購入しました。 関東アクセントとして作成されたもので語尾の2音節目で音程が下がるので かなり自然な音声として使用できました。ただ「UNIX」とかくと ゆー・えぬ・あい・えっくす と発声するので希望する音声を出すのにはいくらか手を加えなければなり ませんでした。 これと簡単な動画を組み合わせれば可能なことです。 ただ、必要か否かの判断あるいは文化の問題でしょう。 > > ということで、現状では幻を容認するという仕様になっています。 > > −−−−−−−−−−−−−−−−−−−− > わかりました。 > > はい。ただし、 allow_read/write @ANY_PATHNAME を与えるのなら、 > http://tomoyo.sourceforge.jp/2.3/chapter-9.html で示されているように、 > そのドメインに対して CONFIG::file::open={ mode=disabled } なプロファイル > （例えば学習モード用なら > > 4-CONFIG::file={ mode=learning } > 4-CONFIG::file::open={ mode=disabled } > > ）を作成して割り当てる方が、パフォーマンス面で有利です。 > > −−−−−−−−−−−−−−−−−−−− > これは、今、理解できていません。ご指摘の文書を読んでみます。 > > > 「ioctlもsecurity moduleも難しいから、もうDACに任せてしまおう」と書かれ > > > ています。必要な（許可すべき）パラメータがわかっていれば、TOMOYOの > > > 出番だと思うのですが。 > > > > > いや、そうでもないですよ。 ioctl の嫌なところは、 read や write で処理するのに > 向かない処理を行うことです。モジュールが独自に定義した任意の構造体を、複数回に > 分けてユーザ空間から読み込んだりすることもあります。これの何が問題かというと、 > ユーザ空間から読み込む内容が、 TOMOYO によるパラメータに基づく可否判断を通過 > してから実際に処理されるまでに書き換えられてしまう可能性があるということです。 > それを防ぐには、ユーザ空間から読み込む内容をカーネル空間のメモリにバッファリング > してから、 TOMOYO による判断を行う必要があるわけですが、そのためには、コピーが > 行われた後に TOMOYO の処理を呼び出す（つまりＬＳＭフックを挿入する）必要が > あります。 > > 例えば Android の /dev/binder のソースコードである > http://android.git.kernel.org/?p=kernel/common.git;a=blob;f=drivers/staging/android/binder.c;h=2d097aa8f7b92254037e9e9707e23e98a87fd3cc;hb=b0d93fb0426911d0329f861f22c59f1c72cff815 > に含まれている全ての copy_from_user() の直後に TOMOYO のフックを挿入することを > 想像してください。それぞれの copy_from_user() で扱う構造体ごとに、それぞれ > パラメータの形式があるわけです。 '\0' で終わる文字列かもしれませんし、 > '\0' では終わらないバイト列かもしれませんし、数値かもしれません。 > ワイルドカードによるマッチングに向くものも向かないものもあるでしょう。 > もはや手のつけようが無い複雑さです。コマンド番号を制限するので精一杯です。 > > > > > 面倒なのは理解できますが、たかが32とか64くらいしかないものにねをあ > > げるのは残念です。 > > 整理すれば、周智のこととして扱えるのでは無いでしょうか。 > > > いえいえ、 ioctl の処理というのはストアドプロシージャみたいなものです。 > パターンは無限に考えられます。 > > ＃ TOMOYO のポリシーのロード処理を read ではなく ioctl を使うようにすれば、 > ＃１回のシステムコールの中で読み込みと書き込みを同時に行うことができるので、 > ＃エラーを報告するのには便利なのですが・・・。かつて ioctl でポリシーを読み書き > ＃することに対して Linus さんが反対（ http://lkml.org/lkml/2007/11/5/129 ）した > ＃ことがあります。 > 知らないと言うことは無謀なことですね。勝手なことを言って申し訳あり ません。 -- 早間
TOMOYO
Fork