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

[Hiroaki TAKADA]

高橋様、皆様

考えやすい喩えに提示、ありがとうございます。

> 具体的には、簡単に書くため、保護機能カーネルの用語で書きますが、
> 保護ドメインというものに対してアクセス許可ベクタ
> と呼ばれるものをつけることです。
> つまり、保護ドメインもひとつのカーネルオブジェクトにして保護対象
> にすることです。
> 現状のμITRON4.0/PXの仕様では保護ドメインは単なる番号付けされたもの
> のようです。

ご指摘の通り、現状のμITRON4.0/PX仕様およびTOPPERS新世代カーネル
仕様では、保護ドメインをカーネルオブジェクトとして扱っていません。
これは、現状、保護ドメインを動的に生成する機能や、保護ドメインを
操作する機能がないことから、カーネルオブジェクトとして扱う必要性
がないためです。

保護ドメインを動的に生成する機能を設ける場合には、保護ドメインを
カーネルオブジェクトとして扱い、それに対してアクセス許可ベクタを
つけるのは自然な拡張だと思います。

参考までに、TOPPERS/RLLに含まれるカーネルでは、保護ドメインを動的
に生成／削除する機能を持っていますが、保護ドメインを生成／削除で
きるのはカーネルドメインに限定しており、保護ドメインにアクセス許
可ベクタはつけていません（高橋さんの喩えを使うと、会社が新規に入
居する時の手続きは、管理会社がやるしかないというコンセプトになり
ます）。

> 保護ドメインに対して、対保護ドメインについてどこを許可可能、許可禁止
> かを
> あらかじめ設定することができれば、許可したくない保護ドメインに対して
> 生成時に禁止できるものと考えています。現在の仕様にはその仕組みがあり
> ません。
> 自社だけアクセス可能なカードは発行できるが、他社までアクセスできるカ
> ード
> を発行しようとしてもエラーになってできないようにする仕組みです。

保護ドメインにアクセス許可ベクタをつけるだけでは、これは実現でき
ないように思います。

例えば、保護ドメインAに対して、保護ドメインAに属するタスクを生成
することは許すが、それ以外の保護ドメインに属するタスクは生成させ
ないという例を考えてみます（より適切な例があればご提示ください）。

現仕様でこれを実現するには、cre_tsk を呼び出せるのはカーネルドメ
インに限定しておき、保護ドメインXが保護ドメインXに属するタスクの
みを生成できる restricted_cre_tsk という機能を、拡張サービスコー
ルとして用意する方法があります。

このように、より細かなアクセス制御を実現したい場合には、拡張サー
ビスコールを用いる方法があります。アクセス制御のポリシーは、アプ
リケーションによる違いが大きいと思われるので、カーネルに入れるの
ではなく、拡張サービスコールとして用意する方が良いという考えで現
状の仕様はできています。

ただし、このようなアクセス制御ポリシーが実現できれば、多くのアプ
リケーションで使えると言った汎用性の高いアクセス制御ポリシーがあ
れば、それをカーネルで実現することや、それを実現する拡張サービス
コールをミドルウェアとして提供することが有効と思われます。

高田広章
名古屋大学

(11/11/04 6:46), kazuhiro takahashi wrote:
> ユーザー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の仕様では保護ドメインは単なる番号付けされたもの
> のようです。
> 
> 込み入った話ですが、なにか思い違いしている部分や、それ以外にも
> ご意見いただければと思います。
> 
> ----
> アライブビジョンソフトウエア株式会社
> 高橋和浩
>