Chromium Sandbox を用いた保護モード
Chromium Sandbox は，乱暴に言えば
- 対象プロセスの権限や動作をとにかく制限する
- それだと目的の動作もできなくなることがあるので，本当に必要な処理についてはより強い権限を持ったプロセスで代理処理する
という二段構成になっています．
2. の代理処理は，Sandbox 化されたプロセス内での API 呼び出しをフックして行います*1．悪意のあるコードが API フックを回避し，本来のシステムコールに到達した場合，プロセス本来のアクセス権限によるチェックが行われます．このケースまで想定して，前者の「とにかく」のレベルが決まります．
1. の制限は強ければ強いほど良いため，Chromium Sandbox では，先ほど出てきた整合性レベルに加え，プロセスのアクセストークンからの権限削除，Job を利用した制約，デスクトップ分離などさまざまなテクニックが使われています．実際には，アプリケーション本来の目的を阻害するような制約は諦めざるをえないため，アプリケーションごとにどの制約を組み合わせるかを選択します．Adobe Reader のケースでは，一部の設定について PC 管理者がカスタマイズすることを許可しています．
Adobe Reader に関しては，次の文献などで詳細な解析が行われています．
http://media.blackhat.com/bh-us-11/Sabanal/BH_US_11_SabanalYason_Readerx_WP.pdf
Chromium Sandbox のような特殊な環境で IME が動作しているとき，正常に動作しているかどうかを判断するのは難しいものがあります．多くの場合，プロセスを起動するような操作しばしば失敗します．これは，辞書ツールや文字パレットが別プロセスとして実装されているケースでは明らかになるでしょうが，これらのツールが対象プロセス内に表示されるウィンドウとして実装されている場合には表面化しないかもしれません．IME の確定履歴がディスク上に書き込めないというケースもあります．Process Monitor でのログを見るだけで問題が明らかになることもありますが，いずれにせよ IME についての理解は必要です．
*1:AdHoc なルールを透過的に適応するという点では Windows の互換性スイッチに似ているとも言えます
