tmyus****@mail*****
tmyus****@mail*****
2005年 11月 20日 (日) 12:27:23 JST
> TOMOYO Linuxは使い始めると比較的容易に管理できるのですが、 > ポリシーを学習し、それに基づいてアクセスを制御するまでの > 環境構築がSELinux等より難しいことに気がつきました。 > > 情報としては、http://tomoyo.sourceforge.jp/ にある内容で > 提供されていますが、利用者およびこれから導入してみようと思う人に > とっての指針が不足していますし、(情報が多いが故に)行うべき手順が > 見えにくくなっています。この状況を改善するために、現在、 > TOMOYOカーネルの構築から最初のポリシー学習とアクセス制御を行う > までの流れの資料化を行っています。 有り難う御座います。 > > >root のログインシェルを falsh にして、 > > >全員が root としてログインしてもらいます。 > > >ここまではドメイン遷移は共通です。 > > >その後で役割に応じて異なる追加の認証プログラムを > > >実行することでドメイン遷移を分割することができます。 > > >例えば、 > > >「ログインシェルから honey を実行するとＷｅｂサービスの管理だけが行なえる」 > > >「ログインシェルから candy を実行するとＦＴＰサービスの管理だけが行なえる」 > > >みたいな使い方です。 > > 元のメールが送信された際に説明を補足しようかと思ったのですが、 > honey, candy, groovyについては、あくまで「セキュリティ強化OSによる > ログイン認証の強化手法」の「実装例(サンプル)」として、TOMOYOのリリースに > 含まれているプログラムの名前であり、TOMOYO Linuxの固有の > 名称ではありません。サンプルなので、それらのファイルを削除しても > TOMOYOは構築、利用できますし、違う名前にしても他の > identifierの名前を変更するような影響は生じません。 > > これは私の考えなのですが、個別の名称を持つ必要のないものに > こうした個別の名前を持たせるべきではないと思っています。 > honey, candy, groovyは、auth1, auth2, auth3のような > 名前が本来ふさわしいのです。実際、Linux Kernel Conference 2005で > 講演を行った際には、デモの中でauth1, auth2, auth3の名前で > 操作、ポリシーの説明をしています。 そのあたりは、一応きちんと理解しているつもりです。 falsh以外は、名前自体に意味はありませんからその方が良さそうですね。 しかし、個別に見ていくと、名称に意味があるように思えますが、honey, candy, groovyの３つが集まると、「一部の人間」には、 groovy=auth1,honey=auth2,auth3=candy, と対応付けられるので問題ありません(ぇ > > しかし、逆を言えばTOMOYOでは、「プログラムを実行するたびにドメイン遷移を行なう」ので、 > > 「su」コマンドは、事実上使えないと言う事でいいんですよね？ > > (まぁ、それぐらいの制約があっても不便だとは思いませんが) > > SELinuxでは、一部ユーザランドのプログラムをSELinux対応に > 置き換えていますが、TOMOYO Linuxについては特にそのような必要が > ありません(これもTOMOYO Linuxの特徴のひとつです)し、特に制約も > 存在していません。「suコマンドが事実上使えない」という意味が > よくわからないのでもう少し説明いただけませんか？ 今見ると、自分勝手に理解して、かなり言葉がしすぎています飛躍しています。 すいません(^^; (よくみると、文章全体のテンションがかなり高いな?(笑) falsh -> honey -> candy -> bash で、入ったとして、suで、 falsh -> groovy -> honey -> candy -> bash に成れるかと言う事です。 falsh -> honey -> candy -> bash から、呼び出されたsuコマンドの ドメインは、 falsh -> honey -> candy -> bash -> su になると思うのですが、suから呼び出すfalshのドメインは、 falsh -> honey -> candy -> bash -> su ->falsh または、 su -> falsh となると思ったので、そこから、-> honey -> candy -> bashと入っても、 su -> falsh -> groovy -> honey -> candy -> bash なって、ドメインが変わってくるのではないかと考え、 suが使えないのではないかと、考えたわけです。 > > あと、開発コードSAKURA,TOMOYO,CERBERUS,YUE の「正式名称」は分かったのですが、 > > SYAORANの「正式名称」をよければ教えてください(笑 > > (>_<) > 「正式名称」ですが、TOMOYO Linuxおける「正式名称」はTOMOYOだけです。 > 半田からのメールに「CERBERUS という開発コードの正式名称は論文の > タイトル欄に英語で書かれています」とありますが、これは正しくは > 「CERBERUS という開発コードの略称の意味は論文のタイトル欄に > 英語で書かれています」が正しいです。ここで言う論文とは、 > 情報学ワークショップ2005で発表した「セキュリティ強化OSにおける > ログイン認証の強化手法」のことを指しており、確かにその論文の > 英文タイトルは「Chained Enforceable Re-authentication Barrier Ensures > Really Unbreakable Security(連鎖して執行可能な認証による破れない障壁)」と > なっていますが、私としてはCERBERUSをTOMOYO Linuxの > 「正式名称」の一部として認定したつもりはありません。 別に困らせる気はありませんでした。 TOMOYO Linuxは、Task Oriented Managementあたりが、他のどれよりもcoolですよね。 YUEでは、「Rule」の「R」がないのに上手く対処(?)しているのも素晴らしい。 SYAORANでも、「Device」の「D」がないが、どのように対処(?)されているのかが 気になっただけです。 開発コードに正式名称も何もありませんよね(開発コード＝正式じゃないのですから)。 昔聞いた話したでは、東京の人は開発コードに意味を持たせたがるものみたいですが 大阪の人は、どちらかと言うと開発コードは士気高揚のためのものみたいです。 東京のとある商社のシステムの開発コードが「SUCCESS」(勿論、何かの略)だったとしても、 大阪に行けば、同じようなシステムでも、「OKAN」(意味はない)ですから。 「SUCCESSが動かない」よりも「OKANが動かん」の方が楽しいですよね (どちらも、大変である事には変わりはないが・・・（苦笑) > という事を言い出すと、「正式名称とは何か？」という非常に難しい話に > なってしまうのですが、私は「人々に対象を指す言葉として広く認知され、 > かつ主体によりオーサライズされた言葉」だととらえています(今このメールを > 書きながら考えた説明です)。TOMOYO Linuxプロジェクトにおいては、 > 一応私がプロジェクトマネージャとしてオーサライズすることになっているので、 > 私がオーサライズしていないと言っている以上正式名称ではありません。 > では何がオーサライズされているかというと、Linux Conference 2004で > 発表した論文の日本語タイトル 「TOMOYO Linux-タスク構造体の拡張に > よるセキュリティ強化 Linux」における"TOMOYO Linux"は正式名称です。 > ただ、タイトルを例外として、プログラムの中で使う関数、モジュール名に > ついては他者に迷惑をかけない範囲で、好きな名称を使って良いし、 > 機能の名称についてその略称が、既存のキャラクターと一致するくらいの > ことはあっても良いのではないかと考えています。プログラムに > 限らなくても自分が好きな作品や人物の名前、あるいはその一部を > 使ったりすることはあるわけですし、知る人が見ればわかるくらいの事は > (他者に迷惑をかけない限り)遊び心として許して欲しい気はします。 むしろ、遊び心がないとダメでしょう。 そもそも、Linuxと言う名前自体、遊び心から生れた言葉で 深い意味はないのですから。 だれも、pingの正式名称やUSAGIプロジェクトの正式名称に、 真剣さ(?)なんて望んでいません。重要なのは中身ですから。 SAKURA Linux, それを受け継いだTOMOYO Linuxに求めるのは、 「絶対 だいじょうぶだよ」なOSです(結局、それかよ)
TOMOYO
Fork