security :: OSASK計画

OSASKのセキュリティに関するページ

• Kが2004.01.08に作成。2chのOSASKスレッドが判断材料不足で困っているようなので。
• ある程度できたらOSASK-MLに報告します。報告しました→[OSASK 6842]。

OSASKアプリのセキュリティに対する考え方

• システムアプリについてはここでは論じない。
• 基本的な考えとして、ファイルアクセス（モジュールアクセス）で守る。メモリはページングとセグメンテーションの2つでガードされているので、干渉できない（OSASKにバグがなければ）。
• OSASKアプリにはroot権限やそれに相当するものがないので、その手のクラックは心配しなくてよい。逆に言うと、システムアプリはroot権限を持っているアプリといえる。そしてシェルから設定しない限り、ユーザアプリはシステムアプリにはならない。
  • マルチユーザ環境下では、あるアプリAをユーザUさんがシステムアプリに設定したとしても、ユーザVさんにはその設定は引き継がれない。
• ユーザの設定次第で特定のアプリに対してセキュリティをキャンセルすることはできるが、OSASKアプリをダウンロードして解凍したら、デフォルトでキャンセルされた状態になる、なんていうのはない。
  • これに反して、そういうことができるシェルを作ることはもちろんできるが、そんな機能があったら（その機能を無効にできてかつデフォルトで無効になっていない限り）そのシェルに対して川合秀実推奨を与えることはない。
• 基本的に、OSASKアプリは4つのアプリディレクトリ以外にはアクセスできない。それ以外のアクセスをするには、絶対にユーザ操作による支援が必要になる。つまり、OSASKアプリは与えられた領土からは出られない。
  • ユーザ操作による支援というのは、たとえばダイアログが出てきてファイルを選ぶとか、CUIのコマンドラインパラメータでファイル名を指定するとか、そういったものである。
  • CUIのコマンドラインパラメータによるファイル名を指定しても、アプリにはファイル名もファイルパスも教えないのが通常の動作であり、したがってそばにあるファイルをアクセスすることはやはりできない。結局破壊することができるのは、指定してもらえたそのファイルのみに限定される。
• DLLを使うとか、他のアプリを起動するなどという場合（註：今のところ一般アプリは他のアプリを起動する権利は持たないという路線で検討している。これがくつがえされたとしての、仮定の話である）、毎回わざわざダイアログを出すのはユーザの不便を強いるので、シェルがアプリ・マシンディレクトリ（インストールディレクトリみたいなもの）に、必要なDLLへのショートカット（OSASKではショートカットとはいわないし、扱いも異なるが、とりあえずこの表現が一番ニュアンスが近い）を置く。アプリは自分のマシンディレクトリに対しては普通にパスを指定してファイルを作ったり、ファイルを開いたりすることができるため、DLLも利用できる。
  • なお、このショートカットは書込み禁止属性がついているのが一般的なので、アプリがDLLをクラックすることはできない。
  • これにより、予期しないDLLが利用されるということはないし、アプリAにはDLLのバージョン1を、アプリBにはDLLのバージョン2を、みたいなことも簡単にできる。
• 設定次第でどうにでもできるという考え方は、もちろん正しいが、以上をくつがえさないと満足に動かないようなアプリは、まず推奨されない。ソースを公開することなく「アプリディレクトリにルートディレクトリへのショートカットを入れておかないと起動しません」みたいなアプリであれば、それは「私はウイルスですよ」と言っているのと同じである。
  • 「実行にはシステムアプリ権限が必要です」と書かれたアプリも同じ疑いの目で見られる。
  • それにもかかわらず自分で許可して自滅するなら、それはユーザの勝手であり、これはもはやOSのセキュリティのレベルでの議論を超えている。
• それぞれのアプリディレクトリには、最大容量を設定することも可能で、これによりある日突然発病してHDDを食い尽くしてシステムを不安定にする、なんていうこともできない。
• ネットワークへのアクセスも、アプリごとに監視されログが残ってシェルから確認でき、変なところへのアクセスがあれば、送受信する前にユーザに確認を取らせることもできるだろう（webブラウザのようにあちこちにアクセスするものについては、ソースが公開されて推奨がついているものを利用するということで、いいのではないだろうか）。

• 重要なことは、つまりこれらの制限があっても、多くのアプリケーションは問題なく作れるか、ということである。
  • もしこの制限があまりに厳しく、頻繁に設定によってゆるめなければいけないものだとしたら、ユーザは制限外し設定に慣れてしまい、警戒感は薄れ、効果はない。

エミュレーション時

• エミュレーションドライバ上で動くアプリは、このような流儀を前提には作られていないという指摘はもちろん正しい。だからOSASK上でwin32アプリを走らせれば、やはりウイルスに感染することがあるのではないか、という懸念はもっともである。
• しかしエミュレーションというのは、なんでもかんでもアプリの言いなりになることではない。アプリが「自分はWindowsの中で動いている」と錯覚させられればいいだけである。しきたりの違いがあれば、それをうまく埋めてやるのが、正しいエミュレーションドライバである。
• 例を挙げよう。たとえばWinアプリをエミュレーションしているとして、Winアプリがmydocumet/word/決算報告2003.docをオープンしたとしよう。
• この時エミュレーションドライバは、まず、このWinアプリのユーザディレクトリに相当するディレクトリを準備し、その中からこのパスをたどってみる。見付かればそのままそれを開く。
• なければ、シェルに対し、次のメッセージとともにダイアログを要求。「mydocumet/word/決算報告2003.docに相当するファイルを選択してください。」
• これでハンドルを受け取り、ユーザディレクトリ内に、mydocument/word/というディレクトリを作り、そのwordディレクトリ内に、「決算報告2003.doc」という名前のショートカットを作って、先ほどのハンドルを割り当てる。
• 以上である。
• DLLオープンの場合は、エミュレータがwin32用のDLLのリストを持っている（これは多分ショートカットを集めたディレクトリとして、エミュレータのアプリディレクトリの中に置くことになるだろう。厳密にはエミュレータはドライバなので、アプリディレクトリとは呼ばないが）。このリストから指定されたDLLを探し出して、やはりwin32アプリのアプリディレクトリにショートカットを作ってやり、処理を続行するだろう。
• レジストリという仕組みはOSASKにはないが、これもアプリごとにローカルでエミュレーションしてやることになるだろう。だから、あるwin32アプリがおかしくなってレジストリを壊しても、他のwin32アプリには影響はない（その代わり、アプリ同士がレジストリを通して連携するのは、少々ややこしくはなるだろうが）。
• このように、エミュレーション時であってもOSASKアプリ風の流儀で処理することはでき、やはり問題はないといえる。

UNIXやWindowsのセキュリティとの違い

• UNIXやWindowsでは、「ユーザ権限」でセキュリティを提供しようとする。つまり、kawaiというユーザが実行ファイルを走らせてこれがバグった場合、他のユーザやrootシステムには影響がないが（OSにセキュリティホールはないと仮定）、kawaiの権限下にある他の全てのファイルは破壊されうる。
• このようなセキュリティは、自分が実行する実行ファイルを常に把握できた時代にあっては十分な仕組みであったが、現在のようにインターネット上でたくさんの実行ファイルを容易にダウンロードして実行してみたりする環境では不安が募ると、Kは考えた。
• だから、それぞれのアプリをアプリディレクトリという部屋に閉じ込めて、何かトラブルがあってもそれより外は安全という風にしたいのである。
• そしてまた、ユーザレベルの垣根も（認証方法がちょっと違うが）まだちゃんと残っている。つまり、ウイルスは2種類の障壁を乗り越えないと、大規模な破壊活動ができないわけである。アプリディレクトリの障壁を超えて、やっとそのユーザのデータを壊せるようになるが、他のユーザにはまだ手が届かない。
  • まあ、簡単にできるのは自滅だけである。自滅というのは、自分のアプリディレクトリを消すということであり、他のものを巻き添えにできないので（ショートカットを消したところで、実体は消えない）、むなしいだけである。
  • いうなれば、ウイルス（＝自分自身）を消去したのだから、一種のワクチン的行為ともいえる。・・・結局おまえは何だったのか？（笑）。

こめんと欄

• この状況でも例えば、自分のディレクトリ内で無駄にファイルにを読み書きしてアクセスを異常に増やし、ほかの（正常なアプリなどの）'アクセスを遅くさせてしまう'ようなウイルスや、無駄な処理を大量に行いＣＰＵにものすごい負荷をかけＣＰＵをほぼ独占し、'処理能力を落とす'ウイルスには対抗できないような気がするのですが。 -- 黒龍 2004-01-09 (金) 17:54:58
• それはまぁどのような構造にしても問題になるわけで。　そのようなシチュエーションに対して考えるべきは「どのようにしてユーザの意図しないバイナリの侵入 / 実行を防ぐか」という事になりますね。 -- 名無しさん 2004-01-09 (金) 23:12:16
• そのウイルスは面白いです。でも、OSASKのタスク管理からすると、ファイルアクセス負荷やCPUアクセス負荷で処理能力を落とすのは限界がありそうです。 -- K 2004-01-10 (土) 00:22:36
• たとえば現状でも、適当に"cons00.h"を使ってコンソールアプリをつくり、ここにfor (;;) { cputc('A', stdout); }してしまうことはできます。これをやると、当然負荷は100%になります。確かにいつもより電気は食っていると思います。しかし、うわー重たい、と感じますか？ -- K 2004-01-10 (土) 00:27:24
• 仮に感じたとしても、すぐに終了できちゃったりしませんか？ -- K 2004-01-10 (土) 00:30:24
• そうですか。　それに遅延書き込み機能でメディアの寿命もそんなに減りませんしね…とここまで考えたが確かメモリの遅延書き込みに使えるサイズを超えたファイルはＨＤＤなどに使用頻度の低い順に書き込まれてしまうので普通のファイルのアクセスはやっぱり遅くなってしまうのではないでしょうか（それにＨＤＤやＣＦなどの寿命も減ってしまう）。 -- 黒龍 2004-01-10 (土) 20:40:34
• ＨＤＤやＣＦなどのアクセススピードは物理的に限界がありメインＲＡＭより遅いですから。 -- 黒龍 2004-01-10 (土) 20:45:40
• ウィンドウクローズシグナルを無視するプログラムは (現状では) 終了できないような。あと、beditcを激しくスクロールさせると、環境によってはかなり重たくなりますね。 -- I.Tak. 2004-01-10 (土) 21:27:31
• 描画処理を増やすとマウスカーソルがちらちらしたりしますし、そういう攻撃を防御できるタスク管理って興味ありです。 -- I.Tak. 2004-01-10 (土) 21:31:40
• まず黒龍さんの指摘から。 -- K 2004-01-10 (土) 23:08:15
• ええと、サイズがでかいと遅延書き込みがあまり利かなくなるというのはまったくそのとおりです。・・・OSASKとしてはそれぞれのアプリディレクトリにリミッタをかけたいと考えています。このリミッタが遅延書き込みが十分に利くサイズよりも小さければ、指摘の問題は起きません（起きる前に検出されて止めるか続行するかを選べる）。 -- K 2004-01-10 (土) 23:12:20
• しかしダイアログで指定したファイルについてはリミッタがないな・・・。うーん、そっちにもリミッタは必要なのか？必要かもなあ。・・・そういうことがしたいときは、できるような方法を考えておきます。 -- K 2004-01-10 (土) 23:17:56
• でもやっぱりアプリによっては大きなファイルを扱うことはあるわけで、しかもその場合は悪意がなくてもライトアクセス急上昇になりそうです。これはしょうがないです。 -- K 2004-01-10 (土) 23:21:27
• そういう場合、ユーザはどのアプリが広い範囲にわたってたくさんアクセスしているのかを、シェルで調べることはできるでしょう。そして、実行頻度をすぐにコントロールしたり、一時停止したりすることもできるでしょう。シェルががんばれば、CPU時間の配分の上限だけではなく、そういう単位時間あたりのメモリやディスクアクセスなどの上限も決めて（単位時間あたりのアクセスページ数みたいなもの）、これが規定値を超えないように制御することもできるかもしれません。 -- K 2004-01-10 (土) 23:28:05
• 次にI.Tak.さんの指摘です。そう、今はウィンドウクローズを無視すると終了できません。これはシェルの手抜きです（毎度ながらすみません）。 -- K 2004-01-10 (土) 23:29:59
• で、beditcをスクロールさせると重くなる件ですが、はい、そういうことはあります。しかし重くなるのはアプリであって、pokonではないと思うんです。というのは、pokonにちょっとでも仕事があれば、すべてのアプリは（どんなにビジーでも）CPU時間を奪われるようになっているからです。これは僕がタスクのグローバルレベルって呼んでいるやつで、シェルさえ直せばそれぞれのアプリも序列をつけられます。そしてどんなときでもシェルは最高位にいるべきだと思います（シェルの一部だけでいいから）。 -- K 2004-01-10 (土) 23:35:14
• これなら、シェルがキーシグナルなどをシグナルボックスに受け取った瞬間にスリープから目覚めて、悪さをしているタスクはシェルが使わなかったCPU時間だけを使うことしかできないわけです。となれば、シェルからすると、（少なくともCPU時間的観点では）いつもどおりフルスピードで、問題があると感じているなら、いつでも問題のタスクを、殺したり、一時停止したり、優先度を極端に下げたり、タスクセーブして片付けたり、できます。 -- K 2004-01-10 (土) 23:38:39
• そういう意味です。・・・で、マウスがちらちらする件は、実はよくわかっていません（苦笑）。ちらちらしないはずだと思っているんですが、実際は確かにちらちらしています。おかしいなあ。バグかなあ。 -- K 2004-01-10 (土) 23:40:02