2: 2004-01-10 (土) 00:30:00  |
現: 2024-01-08 (月) 12:59:02 k-tan |
| - | * OSASKのセキュリティに関するページ | + | TITLE:x |
| | + | * OSASKのセキュリティに関するページ [#u5538876] |
| | -[[K]]が2004.01.08に作成。2chのOSASKスレッドが判断材料不足で困っているようなので。 | | -[[K]]が2004.01.08に作成。2chのOSASKスレッドが判断材料不足で困っているようなので。 |
| | -ある程度できたらOSASK-MLに報告します。報告しました→[OSASK 6842]。 | | -ある程度できたらOSASK-MLに報告します。報告しました→[OSASK 6842]。 |
| | | | |
| - | * OSASKアプリのセキュリティに対する考え方 | + | * OSASKアプリのセキュリティに対する考え方 [#cefd6f7f] |
| | -システムアプリについてはここでは論じない。 | | -システムアプリについてはここでは論じない。 |
| | -基本的な考えとして、ファイルアクセス（モジュールアクセス）で守る。メモリはページングとセグメンテーションの2つでガードされているので、干渉できない（OSASKにバグがなければ）。 | | -基本的な考えとして、ファイルアクセス（モジュールアクセス）で守る。メモリはページングとセグメンテーションの2つでガードされているので、干渉できない（OSASKにバグがなければ）。 |
| | --もしこの制限があまりに厳しく、頻繁に設定によってゆるめなければいけないものだとしたら、ユーザは制限外し設定に慣れてしまい、警戒感は薄れ、効果はない。 | | --もしこの制限があまりに厳しく、頻繁に設定によってゆるめなければいけないものだとしたら、ユーザは制限外し設定に慣れてしまい、警戒感は薄れ、効果はない。 |
| | | | |
| - | * エミュレーション時 | + | * エミュレーション時 [#h4aa68c4] |
| | -エミュレーションドライバ上で動くアプリは、このような流儀を前提には作られていないという指摘はもちろん正しい。だからOSASK上でwin32アプリを走らせれば、やはりウイルスに感染することがあるのではないか、という懸念はもっともである。 | | -エミュレーションドライバ上で動くアプリは、このような流儀を前提には作られていないという指摘はもちろん正しい。だからOSASK上でwin32アプリを走らせれば、やはりウイルスに感染することがあるのではないか、という懸念はもっともである。 |
| | -しかしエミュレーションというのは、なんでもかんでもアプリの言いなりになることではない。アプリが「自分はWindowsの中で動いている」と錯覚させられればいいだけである。しきたりの違いがあれば、それを''うまく''埋めてやるのが、正しいエミュレーションドライバである。 | | -しかしエミュレーションというのは、なんでもかんでもアプリの言いなりになることではない。アプリが「自分はWindowsの中で動いている」と錯覚させられればいいだけである。しきたりの違いがあれば、それを''うまく''埋めてやるのが、正しいエミュレーションドライバである。 |
| | -このように、エミュレーション時であってもOSASKアプリ風の流儀で処理することはでき、やはり問題はないといえる。 | | -このように、エミュレーション時であってもOSASKアプリ風の流儀で処理することはでき、やはり問題はないといえる。 |
| | | | |
| - | * UNIXやWindowsのセキュリティとの違い | + | * UNIXやWindowsのセキュリティとの違い [#ae5657cd] |
| | -UNIXやWindowsでは、「ユーザ権限」でセキュリティを提供しようとする。つまり、kawaiというユーザが実行ファイルを走らせてこれがバグった場合、他のユーザやrootシステムには影響がないが（OSにセキュリティホールはないと仮定）、kawaiの権限下にある他の全てのファイルは破壊されうる。 | | -UNIXやWindowsでは、「ユーザ権限」でセキュリティを提供しようとする。つまり、kawaiというユーザが実行ファイルを走らせてこれがバグった場合、他のユーザやrootシステムには影響がないが（OSにセキュリティホールはないと仮定）、kawaiの権限下にある他の全てのファイルは破壊されうる。 |
| | -このようなセキュリティは、自分が実行する実行ファイルを常に把握できた時代にあっては十分な仕組みであったが、現在のようにインターネット上でたくさんの実行ファイルを容易にダウンロードして実行してみたりする環境では不安が募ると、[[K]]は考えた。 | | -このようなセキュリティは、自分が実行する実行ファイルを常に把握できた時代にあっては十分な仕組みであったが、現在のようにインターネット上でたくさんの実行ファイルを容易にダウンロードして実行してみたりする環境では不安が募ると、[[K]]は考えた。 |
| | --いうなれば、ウイルス（＝自分自身）を消去したのだから、一種のワクチン的行為ともいえる。・・・結局おまえは何だったのか？（笑）。 | | --いうなれば、ウイルス（＝自分自身）を消去したのだから、一種のワクチン的行為ともいえる。・・・結局おまえは何だったのか？（笑）。 |
| | | | |
| - | * こめんと欄 | + | * こめんと欄 [#va9c8a9f] |
| | -この状況でも例えば、自分のディレクトリ内で無駄にファイルにを読み書きしてアクセスを異常に増やし、ほかの（正常なアプリなどの）'アクセスを遅くさせてしまう'ようなウイルスや、無駄な処理を大量に行いＣＰＵにものすごい負荷をかけＣＰＵをほぼ独占し、'処理能力を落とす'ウイルスには対抗できないような気がするのですが。 -- ''黒龍'' SIZE(10){2004-01-09 (金) 17:54:58} | | -この状況でも例えば、自分のディレクトリ内で無駄にファイルにを読み書きしてアクセスを異常に増やし、ほかの（正常なアプリなどの）'アクセスを遅くさせてしまう'ようなウイルスや、無駄な処理を大量に行いＣＰＵにものすごい負荷をかけＣＰＵをほぼ独占し、'処理能力を落とす'ウイルスには対抗できないような気がするのですが。 -- ''黒龍'' SIZE(10){2004-01-09 (金) 17:54:58} |
| | -それはまぁどのような構造にしても問題になるわけで。 そのようなシチュエーションに対して考えるべきは「どのようにしてユーザの意図しないバイナリの侵入 / 実行を防ぐか」という事になりますね。 -- [[名無しさん]] SIZE(10){2004-01-09 (金) 23:12:16} | | -それはまぁどのような構造にしても問題になるわけで。 そのようなシチュエーションに対して考えるべきは「どのようにしてユーザの意図しないバイナリの侵入 / 実行を防ぐか」という事になりますね。 -- [[名無しさん]] SIZE(10){2004-01-09 (金) 23:12:16} |
| | -たとえば現状でも、適当に"cons00.h"を使ってコンソールアプリをつくり、ここにfor (;;) { cputc('A', stdout); }してしまうことはできます。これをやると、当然負荷は100%になります。確かにいつもより電気は食っていると思います。しかし、うわー重たい、と感じますか？ -- ''K'' SIZE(10){2004-01-10 (土) 00:27:24} | | -たとえば現状でも、適当に"cons00.h"を使ってコンソールアプリをつくり、ここにfor (;;) { cputc('A', stdout); }してしまうことはできます。これをやると、当然負荷は100%になります。確かにいつもより電気は食っていると思います。しかし、うわー重たい、と感じますか？ -- ''K'' SIZE(10){2004-01-10 (土) 00:27:24} |
| | -仮に感じたとしても、すぐに終了できちゃったりしませんか？ -- ''K'' SIZE(10){2004-01-10 (土) 00:30:24} | | -仮に感じたとしても、すぐに終了できちゃったりしませんか？ -- ''K'' SIZE(10){2004-01-10 (土) 00:30:24} |
| | + | -そうですか。 それに遅延書き込み機能でメディアの寿命もそんなに減りませんしね…とここまで考えたが確かメモリの遅延書き込みに使えるサイズを超えたファイルはＨＤＤなどに使用頻度の低い順に書き込まれてしまうので普通のファイルのアクセスはやっぱり遅くなってしまうのではないでしょうか（それにＨＤＤやＣＦなどの寿命も減ってしまう）。 -- ''黒龍'' SIZE(10){2004-01-10 (土) 20:40:34} |
| | + | -ＨＤＤやＣＦなどのアクセススピードは物理的に限界がありメインＲＡＭより遅いですから。 -- ''黒龍'' SIZE(10){2004-01-10 (土) 20:45:40} |
| | + | -ウィンドウクローズシグナルを無視するプログラムは (現状では) 終了できないような。あと、beditcを激しくスクロールさせると、環境によってはかなり重たくなりますね。 -- [[I.Tak.]] SIZE(10){2004-01-10 (土) 21:27:31} |
| | + | -描画処理を増やすとマウスカーソルがちらちらしたりしますし、そういう攻撃を防御できるタスク管理って興味ありです。 -- ''I.Tak.'' SIZE(10){2004-01-10 (土) 21:31:40} |
| | + | -まず黒龍さんの指摘から。 -- [[K]] SIZE(10){2004-01-10 (土) 23:08:15} |
| | + | -ええと、サイズがでかいと遅延書き込みがあまり利かなくなるというのはまったくそのとおりです。・・・OSASKとしてはそれぞれのアプリディレクトリにリミッタをかけたいと考えています。このリミッタが遅延書き込みが十分に利くサイズよりも小さければ、指摘の問題は起きません（起きる前に検出されて止めるか続行するかを選べる）。 -- ''K'' SIZE(10){2004-01-10 (土) 23:12:20} |
| | + | -しかしダイアログで指定したファイルについてはリミッタがないな・・・。うーん、そっちにもリミッタは必要なのか？必要かもなあ。・・・そういうことがしたいときは、できるような方法を考えておきます。 -- ''K'' SIZE(10){2004-01-10 (土) 23:17:56} |
| | + | -でもやっぱりアプリによっては大きなファイルを扱うことはあるわけで、しかもその場合は悪意がなくてもライトアクセス急上昇になりそうです。これはしょうがないです。 -- ''K'' SIZE(10){2004-01-10 (土) 23:21:27} |
| | + | -そういう場合、ユーザはどのアプリが広い範囲にわたってたくさんアクセスしているのかを、シェルで調べることはできるでしょう。そして、実行頻度をすぐにコントロールしたり、一時停止したりすることもできるでしょう。シェルががんばれば、CPU時間の配分の上限だけではなく、そういう単位時間あたりのメモリやディスクアクセスなどの上限も決めて（単位時間あたりのアクセスページ数みたいなもの）、これが規定値を超えないように制御することもできるかもしれません。 -- ''K'' SIZE(10){2004-01-10 (土) 23:28:05} |
| | + | -次にI.Tak.さんの指摘です。そう、今はウィンドウクローズを無視すると終了できません。これはシェルの手抜きです（毎度ながらすみません）。 -- ''K'' SIZE(10){2004-01-10 (土) 23:29:59} |
| | + | -で、beditcをスクロールさせると重くなる件ですが、はい、そういうことはあります。しかし重くなるのはアプリであって、pokonではないと思うんです。というのは、pokonにちょっとでも仕事があれば、すべてのアプリは（どんなにビジーでも）CPU時間を奪われるようになっているからです。これは僕がタスクのグローバルレベルって呼んでいるやつで、シェルさえ直せばそれぞれのアプリも序列をつけられます。そしてどんなときでもシェルは最高位にいるべきだと思います（シェルの一部だけでいいから）。 -- ''K'' SIZE(10){2004-01-10 (土) 23:35:14} |
| | + | -これなら、シェルがキーシグナルなどをシグナルボックスに受け取った瞬間にスリープから目覚めて、悪さをしているタスクはシェルが使わなかったCPU時間だけを使うことしかできないわけです。となれば、シェルからすると、（少なくともCPU時間的観点では）いつもどおりフルスピードで、問題があると感じているなら、いつでも問題のタスクを、殺したり、一時停止したり、優先度を極端に下げたり、タスクセーブして片付けたり、できます。 -- ''K'' SIZE(10){2004-01-10 (土) 23:38:39} |
| | + | -そういう意味です。・・・で、マウスがちらちらする件は、実はよくわかっていません（苦笑）。ちらちらしないはずだと思っているんですが、実際は確かにちらちらしています。おかしいなあ。バグかなあ。 -- ''K'' SIZE(10){2004-01-10 (土) 23:40:02} |
| | | | |
| | #comment | | #comment |
