サンドボックス は、アプリケーションが実行できることを制限する方法のようです。今日、私は自分のアプリケーションが自分のコンピューターで何をするかについてあまり制御できません。私のWindowsシステムでネイティブアプリケーションを実行するよりも、JavaScriptベースのWebアプリケーションを使用する方が安全です。
Windowsでアプリケーションがデフォルトでサンドボックス化されない理由は何ですか?
参照 アプリケーションがコンピュータで実行できることをどのように制限できますか?
Windows APIプログラミングについてはあまり知りませんが、次のような任意のプログラムで許可されている場合、いくつかの関数は怖いようです。
Windowsのデフォルトでアプリケーションがサンドボックス化されないのはなぜですか?わかりませんが、以下の理由が混在していると思います。
サンドボックスは、複雑で微妙な方法で多くのアプリケーションを壊します。 Windowsがアプリケーションの1つでも機能しない新しい機能を既定でオンにすると、ユーザーは不満を感じます。デフォルトでオンのサンドボックススキームを設計することは非常に困難です。このスキームは、セキュリティに役立ち、しかもレガシーアプリケーションを壊すことはありません。
歴史的な慣性。 Windowsがこれを行ったことは一度もありません。これは大きな変更になるでしょう。
理解しやすさ:サンドボックス化は、混乱を招き、デバッグが困難なエラーを引き起こす可能性があります。これは、システム管理者の複雑さと認知的負荷を増大させ、システム管理者が修正するのが難しいと思われるクラッシュや障害をさらに増やし、システム管理者を不満にさせる可能性があります。
これを実際に体験するには、Mac App Store経由で販売されるすべてのアプリケーションをサンドボックス化する必要があるというAppleの動きを検討することをお勧めします。 Apple is running to some多少の問題が発生し、その結果、締め切りが遅れている であり、一部のアプリケーションでは機能が大幅に失われるという報告があります。これが最良です開発者が協力し、サンドボックス化の義務に準拠するようにアプリケーションを変更する準備をしている場合。Microsoftがこれをデフォルトですべての変更されていないレガシーアプリケーションにWindowsにデプロイした場合、どのように見えるか想像してみてください。状況はさらに悪化します。
ああ、でもいいですよ!サンドボックス化は新しい概念ではなく、1980年代から存在しています。ただし、おそらくあなたが収集したように、これらのタイプのサンドボックスの制限は、セキュリティの観点からそのポイントに押しやられていますlook不十分です。
サンドボックスと権限モデルについて
説明させてください。コンピュータが起動すると、互換性の理由から(つまり、DOSを実行できるようにするため)16ビットのリアルモードで起動します。追いかけるには、基本的に32ビットプロテクトモードまたは64ビットロングモードに切り替えます。これらは少し異なりますが、かなり似ています。この時点で、x86ベースのCPUはスーパーバイザモードであり、システムコールを実行できるように、ページフォールトやsysenterやソフトウェアの割り込みなどをセットアップして処理する必要があります。数百万行のコードをスキップして、すべてのハードウェアデバイスとtadaを起動します。最初のプロセスが実行されます。
ご存知かもしれませんが、プロセスは、基盤となるシステムメモリについては何も知らずに作成されます。仮想メモリを認識します。また、通常モード(リング3と呼ばれます)で実行されて作成されます。つまり、割り込みハンドラーの設定やページフラグの変更などを行うことはできません。つまり、他のプロセスの存在を確認することはできません(コンピュータが完全に実行されていると "信じている")exceptオペレーティングシステムに問い合わせることはできません。
だから、あなたの平均的な毎日のプロセスisは、ファッションの後にサンドボックス化されています。現在、すべてのプロセス*は、管理者を含め、オペレーティングシステムに処理を依頼する必要があります。それらがcanかどうかを決定するものは...オペレーティングシステムです。
現在、これは主にユーザー権限を介して行われます。プロセスは、実行しているユーザーのコンテキストを継承します。したがって、Windowsカーネルはそのアクセス許可をチェックし、それが管理者であることを確認して「はい、大丈夫」と言うため、管理者ユーザーとして実行されるプロセスは何でも実行できます(例外を除いて、ユーザーモードプロセスは技術的に特定のことを行うことはできませんが、 can可能なカーネルモードプロセス(例:ドライバー)を読み込みます)。同様に、Linuxでは、rootは何でもできると想定されています。
したがって、現在のモデル(そして今私はついにあなたの質問に行きます)は、プロセスが継承し、ユーザーが実行できることを正確に実行できると述べています。
機密性の高いWord文書をディスクに保存してWebブラウザーを実行したい場合を除いて、これは妥当な前提です。 Webブラウザーがユーザーが実行できるすべてのことを実行できるという事実の結果として、Wordを使用してドキュメントを読み取ることができるという事実は、Webブラウザーが望めばそれを実行できることを意味し、これを防ぐための規定はありません。
ありare MACなどのオペレーティングシステム用の、より侵襲的でサンドボックス化されたアクセス許可システムの設計。これらのシステムはすべて、各プロセスが実行できることにさらに制約を受けるという考えの変形を提案しています。そのため、Webブラウザーは、ネットワーク、一時ストレージ、およびダウンロードフォルダーへのアクセスのみを許可されます。私はそれらの取り込みの欠如の理由を尋ねました here そして、一般的なコンセンサスは複雑さであると思われ、主要な要素です。人々理解現在のモデルは、たとえ「すべての迷惑なダイアログを防ぐために管理者として実行する」という単純な理解であってもです。 MACシステムは本質的に複雑です。プロセスを制約するためにプロセスが実行できることの知識が必要です。
他の多くの優れたセキュリティ機能と特定のOSコンポーネントの再構築 必須の整合性制御 の中で、実際に導入された、非常に悪評の高い、非常に嫌われているセキュリティ障害のWindows Vista。これらは、MACタイプのコンポーネントをWindowsに組み込むための何らかの方法です。
したがって、一般的な質問のtl; dr:MACは理解が難しく、実装が複雑です。
これらのAPI呼び出しについて
次に、怖いAPI呼び出しについて:
VirtualProtectEx:指定されたプロセスの仮想アドレス空間でコミットされたページの領域の保護を変更します
WriteProcessMemory:指定されたプロセスのメモリ領域にデータを書き込みます。書き込まれる領域全体がアクセス可能でなければなりません。アクセスできない場合、操作は失敗します。
後者の下部にあるメモをメモします。
書き込まれるプロセスへのPROCESS_VM_WRITEおよびPROCESS_VM_OPERATIONアクセス権を持つハンドルを持つ任意のプロセスは、関数を呼び出すことができます。常にではありませんが、通常、書き込まれているアドレス空間を持つプロセスがデバッグされます。
これらのすべて大文字の値は、Windowsのアクセス許可を表す定数です。その関数を呼び出すことができるのは、プロセスに対するアクセス許可を持っているか、取得できる場合のみです。前者の関数については、次の点に注意してください。
ハンドルには、PROCESS_VM_OPERATIONアクセス権が必要です。詳細については、「プロセスのセキュリティとアクセス権」を参照してください。
プロセス権限の完全なセットについて説明します ここ 。ここで、最も重要なのは、SeDebugPrivilegeが必要であることです。この詳細は Old New Thing で説明されています。
デフォルトでは、ユーザーは自分が所有するプロセスのみをデバッグできます。他のユーザーが所有するプロセスをデバッグするには、SeDebugPrivilege特権が必要です。しかし、この特権を気軽に付与しないでください。一度付与すると、農場を譲渡したためです。
つまり、ユーザーとしてこれらの関数を呼び出してプロセスをデバッグすることは可能ですが、既に所有しているものだけです。アクセス許可モデルでは、ユーザー(実行中のプロセスを含む)が実行できるすべてのプロセスを許可するため、これは予想されることです。自分のプロセスをデバッグすることは合理的な活動ですが、そうです、それは悪用することができます-この能力は現在のモデルの問題の核心です。
次に、GetKeyboardStateに移動します。
アプリケーションはこの関数を呼び出して、すべての仮想キーの現在のステータスを取得できます。スレッドがメッセージキューからキーボードメッセージを削除すると、ステータスが変化します。
GUIを実行しているすべてのWindowsプロセスには、発生したイベントのメッセージキューがあります。これは、イベントを読み取った後、プロセスのキーボードの状態を取得できることを意味しています。ただし、次のことに注意してください。
キーボードメッセージがスレッドのメッセージキューにポストされてもステータスは変化しません。また、キーボードメッセージが他のスレッドのメッセージキューにポストされたり、メッセージキューから取得されたりしても、ステータスは変化しません。 (例外:AttachThreadInputを介して接続されているスレッドは、同じキーボード状態を共有します。)
したがって、はい、AttachThreadInputを使用して他のプロセス入力をフックできます。これには回避策があります- Windows Secure Desktop Modeの仕組み を参照してください。基本的に、Windowsは複数のデスクトップをサポートしており、これらを使用することで、それらにAttachThreadInputを不可能にします。
tl; drこれらの関数を現在のセキュリティモデルと組み合わせることは、現在のモデルのリスクと制限、特に現在のデータとプロセスに対する制限を表しますユーザー;ただし、システム全体でセキュリティ保護のレベルが設定されています管理者ユーザーとして実行していない場合!
サンドボックス化にはさまざまな批判があります。
更新
関連記事: