(toppers-users 3681) Re: 保護拡張仕様(μITRON4.0/PX)の疑問点とその対応アイデア

[Masaki Muranaka]

高橋さん，高田先生，みなさま:

議論進んだところで，ぐるっと引き戻してしまうかもしれないですけれど…．

> また、これは、現状は、動的生成が仕様にも実装にもサポート外であるので静的APIの
> 範囲によって保護違反と思われる定義は人的に防ぐことが可能なため大きな問題でもな
> いと思います。
> ただ、動的生成においてもアクセス保護のついてこの問題を回避できる方法があれば
> それに越したことはないと思っています。

PX型 (≒新世代の保護拡張) のカーネルで，動的生成が求められるかという点を
まず検討せねばならないのではないでしょうか．
仕様として美しいに越したことはないのですが，セキュリティチェックは，
ほぼ全てのサービスコールでオーバヘッドになりますので．

個人的には，「どんなに優れた認証システムを作っても，認証サーバの
コンソールに悪人を置いたら終わり」と見切ったPlan9の考え方を倣って，
悪意の存在しうるタスクは物理的にOSやプロセッサを分けるくらいの姿勢が
妥当な気がしたりしています．


2011年11月4日6:46 kazuhiro takahashi <takahashi_kazuhiro ＠ nifty.com>:
> ユーザーMLの皆様、おはようございます。アライブビジョンソフトウエアの高橋です。
>
> すでに、TOPPERSのセキュリティ対策は話がついていますが、
> 現状のμITRON4.0/PX（およびTOPPERS新世代カーネル統合仕様書でも変わって
> いないと思う部分）について、少し疑問点を挙げてみます。
>
> わかりやすく、テナントビルとその各階に入居企業があり、その入室カードに
> 関する例です。
>
> 入室カード(ICカード）で1F入り口のドアが開きます。さらに各階のドアをあけるカードとします。
> 各階が別々の企業が入っていて、A会社は、2Fのフロア、B会社は3Fのフロアを使って
> います。1F階は管理会社が入っていて、社員一人ひとりのICカードは、1Fの管理会社が
> 発行します。もちろん、A会社の社員は1F入り口と2Fのフロアがアクセス可能、ほか階
> などはアクセスできないICカードになります。B会社も同様に自社の階にアクセスできる
> ものになり他社にはアクセスできないものになります。
>
> 通常は上記の管理としますが、仮に、A会社でも、B会社でもICカードの発行ができ
> さらに、どこの階にアクセス可能にするかを各会社自身がきめることができたり
> することがあるとすればどうでしょうか？
> たとえば、A会社で発行するカードが、2Fも3Fもアクセス可能なカードが発行できて
> しまうことはセキュリティ上問題ではないでしょうか？
>
> ここで保護機能カーネルの話に戻しますが、保護機能はカーネルオブジェクトに
> 保護属性を持たせ、特定の対象からアクセスを禁止するものですが、カーネルオブジ
> ェクトを生成時に許可属性は決められるものの、誰がどのような属性を持たせるかに
> ついては制限がありません。つまり上記のようにA会社がB会社にアクセス可能なICカードが発行できてしまいます。
> 現状の実装や仕様において関係するのは、静的APIにおいて、A会社がB会社にアクセス
> 可能なカーネルオブジェクトの定義ができてしまうことです。
> ただ、これは、可能にしようと意図したのか、間違ってそのように定義したかはわかり
> ませんし、定義したとおりにできるだけです。
> これに関しては、何か別の定義によりA社B社は排他であるような定義を別に設けることで防げることのように思います。
> また、これは、現状は、動的生成が仕様にも実装にもサポート外であるので静的APIの
> 範囲によって保護違反と思われる定義は人的に防ぐことが可能なため大きな問題でもな
> いと思います。
> ただ、動的生成においてもアクセス保護のついてこの問題を回避できる方法があれば
> それに越したことはないと思っています。
>
> そこで、対策として思いついたことは以下のとおりです。
> それは、上記例の標準的な運用では、1Fの管理会社がカードを発行します。
> 1Fの管理会社は、信頼された管理者として属性をもち、ICカードの発行や更新は
> そこだけしかできなくすることがまず考えられます。
>
> ただ、信頼された管理者は、いわばroot権限でありなんでもこいになります。
> 小さなビルでは問題がありませんが、各会社が自分のところが自社で発行するものと
> なると考えます。1Fの管理会社にドロボーがはいったら、全フロアがアクセス可能
> になってしまいます。
>
> そうなってくるとたとえばA社はB社にアクセスできないということが
> カード生成時にチェックされて発行できないというカード発行機を1Fの管理会社が
> 各会社に配布すればよいと考えます。
>
> つまりカード発行において、カード生成時にどのアクセス対象に対して許可できない
> ということを覚えこんでおき、許可するカードを生成しようものならエラーと
> なるようにすればよいと考えます。
>
> それを
> 保護機能カーネルの仕様の話にないますが、現在の仕様上の用語では、アクセスの可否は保護ドメインという
> グループ分けした集合で管理する仕組みになっています。
> つまり例で言う会社は保護ドメインの例えになります。
> 保護ドメインに対して、対保護ドメインについてどこを許可可能、許可禁止かを
> あらかじめ設定することができれば、許可したくない保護ドメインに対して
> 生成時に禁止できるものと考えています。現在の仕様にはその仕組みがありません。
> 自社だけアクセス可能なカードは発行できるが、他社までアクセスできるカード
> を発行しようとしてもエラーになってできないようにする仕組みです。
>
> 具体的には、簡単に書くため、保護機能カーネルの用語で書きますが、
> 保護ドメインというものに対してアクセス許可ベクタ
> と呼ばれるものをつけることです。
> つまり、保護ドメインもひとつのカーネルオブジェクトにして保護対象
> にすることです。
> 現状のμITRON4.0/PXの仕様では保護ドメインは単なる番号付けされたもの
> のようです。
>
> 込み入った話ですが、なにか思い違いしている部分や、それ以外にも
> ご意見いただければと思います。
>
> ----
> アライブビジョンソフトウエア株式会社
> 高橋和浩
>
>