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

[Hiroaki TAKADA]

高橋様、皆様

今の仕様では、カーネルドメインを完全に無くしてしまうことは難しいと
思いますが（ISR等がカーネルドメインにしか入れられないため）、カーネ
ルドメインに入れるものを最小限にするという方針は有益と思います。

> 1)の説明になりますが、アクセス許可ベクタは
> おおよそ4種類の操作に対する許可パターンを持ちます。実現する方法と
> して操作のひとつとして
> 生成削除の可否を持たせればよいと考えます。

確認ですが、保護ドメインに属するオブジェクトの生成削除ができるかどう
かを、保護ドメインの（アクセス許可ベクタの内の１つの）アクセス許可パ
ターンで制御しようというご提案ですね？（前のメールでは、保護ドメイン
自身の生成削除を制御する話しに読めたので、その点を誤解していました）

上の確認通りであれば、ご提案は了解です。現行仕様では、オブジェクトを
生成するサービスコールが呼べるかどうかは、システム状態のアクセス許可
ベクタで制御する仕様となっていますが、それよりは良い案に思えます（オ
ブジェクトの削除の方は、そのオブジェクト自身のアクセス許可ベクタで制
御する現行仕様でも問題ないように思えます）。

今後、保護機能＆オブジェクト動的生成を実現する際（早くそこまで開発を
進めたいですね…）には、有力な仕様案として検討したいと思います。忘れ
ないように、統合仕様書のTracにチケットを発行しておきます。

高田広章
名古屋大学

(11/11/04 13:54), 高橋和浩@nifty wrote:
> お世話になります、アライブビジョンソフトウエアの高橋です。
> 
> 
> 
> On Fri, 04 Nov 2011 12:30:35 +0900
> Hiroaki TAKADA<hiro ＠ ertl.jp>  wrote:
> 
>> 高橋様、皆様
>>
>> 考えやすい喩えに提示、ありがとうございます。
>>
>>> 具体的には、簡単に書くため、保護機能カーネルの用語で書きますが、
>>> 保護ドメインというものに対してアクセス許可ベクタ
>>> と呼ばれるものをつけることです。
>>> つまり、保護ドメインもひとつのカーネルオブジェクトにして保護対象
>>> にすることです。
>>> 現状のμITRON4.0/PXの仕様では保護ドメインは単なる番号付けされたもの
>>> のようです。
>>
>> ご指摘の通り、現状のμITRON4.0/PX仕様およびTOPPERS新世代カーネル
>> 仕様では、保護ドメインをカーネルオブジェクトとして扱っていません。
>> これは、現状、保護ドメインを動的に生成する機能や、保護ドメインを
>> 操作する機能がないことから、カーネルオブジェクトとして扱う必要性
>> がないためです。
>>
>> 保護ドメインを動的に生成する機能を設ける場合には、保護ドメインを
>> カーネルオブジェクトとして扱い、それに対してアクセス許可ベクタを
>> つけるのは自然な拡張だと思います。
>>
>> 参考までに、TOPPERS/RLLに含まれるカーネルでは、保護ドメインを動的
>> に生成／削除する機能を持っていますが、保護ドメインを生成／削除で
>> きるのはカーネルドメインに限定しており、保護ドメインにアクセス許
>> 可ベクタはつけていません（高橋さんの喩えを使うと、会社が新規に入
>> 居する時の手続きは、管理会社がやるしかないというコンセプトになり
>> ます）。
>>
> そうですね。TOPPERS/RLLがそのような動作とするならば、1Fの管理会社が
> カードを発行する仕様になっているということになりますね。
> 
> 
>>> 保護ドメインに対して、対保護ドメインについてどこを許可可能、許可禁止
>>> かを
>>> あらかじめ設定することができれば、許可したくない保護ドメインに対して
>>> 生成時に禁止できるものと考えています。現在の仕様にはその仕組みがあり
>>> ません。
>>> 自社だけアクセス可能なカードは発行できるが、他社までアクセスできるカ
>>> ード
>>> を発行しようとしてもエラーになってできないようにする仕組みです。
>>
>> 保護ドメインにアクセス許可ベクタをつけるだけでは、これは実現でき
>> ないように思います。
>>
> 
> ちょっとよくわかりません。実現できると思っています。
> 
>> 例えば、保護ドメインAに対して、保護ドメインAに属するタスクを生成
>> することは許すが、それ以外の保護ドメインに属するタスクは生成させ
>> ないという例を考えてみます（より適切な例があればご提示ください）。
>>
> 
> 自分が提示する方法は違うポリシーにする例かと思いますが、
> 
>> 現仕様でこれを実現するには、cre_tsk を呼び出せるのはカーネルドメ
>> インに限定しておき、保護ドメインXが保護ドメインXに属するタスクの
>> みを生成できる restricted_cre_tsk という機能を、拡張サービスコー
>> ルとして用意する方法があります。
>>
>> このように、より細かなアクセス制御を実現したい場合には、拡張サー
>> ビスコールを用いる方法があります。アクセス制御のポリシーは、アプ
>> リケーションによる違いが大きいと思われるので、カーネルに入れるの
>> ではなく、拡張サービスコールとして用意する方が良いという考えで現
>> 状の仕様はできています。
> 
> とりあえず、1Fの管理会社に発行をさせるのを拡張サービスコールという
> 方法で行うというものですね。了解しました。この方法で、1Fの管理会社が
> すべての入居企業用のICカードを発行する拡張はできると思います。
> 
> ただ、上記にも書きましたが
> 1)実現できないということは無いです（保護ドメインに関してアクセス許可ベクタ化によって）
> 2)例示するセキュリティポリシーの前提が違います。
> 
> 2)から説明しますが、セキュリティポリシーとして、この上にメールで指定したようにCOOPコウベネット
> からの話でもあります。つまり、内部ユーザからの不正アクセスに備えるべきという話のつもりです。
> 
> つまり、1F管理会社がドロボーに入られたらすべての
> セキュリティが無効になります。ですので、個々の保護ドメインに対して
> 個別に生成、削除をする権限を与える方法です。同じ保護ドメイン内もしくは限られた保護ドメイン内
> でしか被害が及ばないものを考えています。
> 
> 1)の説明になりますが、アクセス許可ベクタは
> おおよそ4種類の操作に対する許可パターンを持ちます。実現する方法として操作のひとつとして
> 生成削除の可否を持たせればよいと考えます。つまりカーネルドメインそのものを無くしてしまい、
> カーネルドメインでの許可を限られた保護ドメイン間で行えるようにすることです。
> そうすることで、A会社は、2Fにアクセス可能なICカードはいくらでも発行可能になり、
> B会社は3Fにアクセス可能なICカードはいくらでも発行可能です。
> A会社にドロボーが入られても、B会社に影響もないですし、1Fの管理会社がなければ全テナントに
> およぶ被害には合わないと考えます。
> 
> また、部分的にもカーネルドメインの権限のまま動作させることに対する危険性についても
> 一応考え方を述べます。
> 
> 許可ベクタの1操作として動的に禁止してしまう方法も考えられると思っています。
> sac_dom()にて、操作の2番目のパターンが自分自身の変更を許可禁止にする。
> ただし、禁止してしまうと、もう、許可することができなくなってしまいますが、
> それはそれでセキュアではないかと考えています。
> 
>> このように、より細かなアクセス制御を実現したい場合には、拡張サー
>> ビスコールを用いる方法があります。アクセス制御のポリシーは、アプ
>> リケーションによる違いが大きいと思われるので、カーネルに入れるの
>> ではなく、拡張サービスコールとして用意する方が良いという考えで現
>> 状の仕様はできています。
>>
>> ただし、このようなアクセス制御ポリシーが実現できれば、多くのアプ
>> リケーションで使えると言った汎用性の高いアクセス制御ポリシーがあ
>> れば、それをカーネルで実現することや、それを実現する拡張サービス
>> コールをミドルウェアとして提供することが有効と思われます。
> 
> すでにコメントしているとおりなのですが、
> アクセス制御ポリシーとして、いわゆるroot権限でのパターンなので
> COOPコウベネットのケースでは、有効性が薄いと考えています。
> 上記のような拡張サービスコールの拡張によってrootによる集中権限以外の
> 方法がとれるかどうかはよくわかりません。そういう方法もあるのかもしれません。
> 
> ただ、カーネルの標準的な機能で、いわゆる権限の分散する方法がとれるほうが
> 有効な手法だと考えています。　一般的にRTOSユーザーが拡張サービスコールを
> どのように実装すれば実現できる機能を考えなければならないというのも
> RTOSをセキュアに使う上でのハードルを高く設定しているように思います。
> 
> ご意見いただければ幸いです。
> 
> 
> ---
> アライブビジョンソフトウエア株式会社
> 高橋和浩
> 673-0005兵庫県明石市小久保2-2-7幹線ビル4F
> Email:takahashi_kazuhiro ＠ nifty.com
> http://homepage3.nifty.com/ALVS/
>