Future Technology Days ～ Windows 7 セミナー (4)

こんにちは、naginoです。

今回は最後の Break Out Session を振り返ります。

● どう変わる？ Windows 7 & Vista アプリケーション開発 ～セキュリティ対応～

このセッションは開発寄りのセッションでした。

ハンズオンの数が少なく、受け取れませんでした。

このセッションでは、全ての前提としてのリソース管理と IL、実際のセキュリティの仕組みである UAC、UIPI、IE 保護モード、セッション 0 の分離、WRP を順に説明し、最後にセキュリティ対応を考慮したアプリケーションの設計について説明するという流れでした。

順に振り返ります。

・リソース管理

基本的には Vista と同じで、セキュリティの観点からはアカウントは 3 種類（標準、Administrators、Administrator）に分類されます。

Administrator は、基本的には Administrators の中の 1 アカウントですが、常に管理者トークンが使用される点が特殊です。

ディレクトリ構造は、大きくマシン全体に関する領域とユーザー別領域とに分かれました。

それぞれ以下の権限が必要になります。

マシン全体 ： 書き込み ⇒ 管理者権限

： 読み込み ⇒ ユーザー権限

ユーザー別 ： 書き込み ⇒ ユーザー権限

読み込み ⇒ ユーザー権限

また、フォルダ構成が大きく変わりました。

単純にパスが変わっただけではなく、環境変数の追加もあり、また「ディレクトリの接合」という仕組みが導入されたそうです。

「ディレクトリの接合」というのは、古い環境変数のパスへの書き込みをユーザー別領域の所定の場所へリダイレクトする機能のようです。

過去のアプリケーションが動作するために存在する仕組みのようですが、読み込みはリダイレクトしないため、インストールはできるが動作しないなど色々トラブルを起こす原因になっているようです。

・IL（Integrity Level / 整合性レベル）

これは Vista や 7 のセキュリティ機構の基礎となっているもので、プロセスやファイル、レジストリといった様々なオブジェクトに関してアクセスできるレベルを管理する仕組みのようです。

レベルは以下の 3 つに分かれています。

高 IL：管理者権限

中 IL：標準権限

低 IL：信頼できない権限（IEの保護モードで使用）

管理者権限を持つ Administrators のアカウントでログオンしても UAC が表示されるのは、この中 IL と高 IL 両方が発行され、普段は中 IL のトークンが使用されるからのようです。

# トークンと IL って関連するものとして理解しているのですが、もしかして違うかもしれません。

・UAC（User Account Control）

トークンのフィルタリングで実現している、と話していました。

管理者アカウントでログオンしても、標準ユーザーと管理者の 2 つのトークン（フルトークンとフィルタ済みトークン）が発行され、普段はフィルタ済みトークンが使用される仕組みになります。

UAC のダイアログで許可すると初めて管理者承認モードとなり、フルトークンが使用されます。

UAC のダイアログの帯の色は、実行ファイルの署名で変化するため、自作のアプリケーションに対しては適切な署名が好ましいとのことでした。

また、UAC は 7 になってデフォルト設定が変更になり、必要の無い限り出なくなりました。（例えば Windows System 提供の場合は出ない）

また、コントロールパネルにスライダで簡単に UAC の設定を 4 段階で変更できるようになり、Vista のセキュリティポリシーで一つ一つ設定する必要があったのに比べると非常に扱いやすくなっています。

逆に言えば、Vista でもセキュリティポリシーを適切に設定すれば、必要の無い限り出ないようにできるかもしれません。（未確認）

なお、UAC のダイアログではなくアプリケーション実行時に管理者承認モードにするには、以下の 3 通りの方法があるそうです。

- 実行ファイルを右クリックして「管理者として実行」

- プロパティタブの「互換性タブ」で設定

- Manifest で権限指定（RequestExequsionLevel）

あとは、インストーラの自動検出などで例外的に出ることがあるそうですが、これはファイル名などで判別されてしまい、また 32bit で標準ユーザー実行し、Manifest が無い場合のみに限定される保険のような機能のため、Manifest を適切に用意するのが鉄則とのことです。

・ファイルとレジストリの仮想化

標準ユーザーで書き込みを行うときに権限が足りない場合、自動でリダイレクトされるそうです。

こちらも 32bit / 標準ユーザー / Manifest 無しが条件ですが、ディレクトリの接合とは異なり、読み書き両方がリダイレクトされるそうです。（なぜディレクトリの接合は書き込みのみなのかが謎ですが・・・。）

そのため、Vista 非対応のアプリケーションで C:\Program Files にインストールしていないアプリケーションは、この機能によってとんでもないところにインストールされている可能性があるようです。

ここで話が少しそれて、インストール時のアプリケーション初期設定の話になりました。

インストーラによるインストール中は、前述のインストーラの自動検出などもあり、大抵は管理者権限で実行されているのですが、このときはマシン全体の領域に書き込みが行えます。

ここでうっかりその領域に設定情報を書き込むと、以後通常起動すると設定変更などができない事態になります。

このため、Vista / 7 対応のアプリケーションは、アプリケーション自体の初回起動時に初期設定を行うようにするべきだそうです。

実際 Visual Studio や SQL Server Management Studio などの最近のバージョンは、どれも初回起動時に設定を行っています。

また、シールドアイコンは、実行ファイルへは Manifest によって自動的につくが、ボタンなどにはコードで BCM_SETSHIELD で明示的に設定する必要があるということでした。

また、アプリケーションのうち管理者権限が必要な箇所は別の実行ファイルにまとめ、それを ShellExecute() で起動することで、最小権限の付与が行えるとのことでした。

・UIPI

ウィンドウメッセージや DLL 注入から保護するため、権限が低いアプリケーションから権限が高いアプリケーションへの SendMessage が失敗するようになり、それを UIPI（UI特権？）というそうです。

そのような必要がある場合は、もちろん権限昇格しても可能だがそれではセキュリティの意味が無いので、Manifest で uiAccess を設定することで対応できるそうです。

ただし署名つきでインストールした場合のみ有効とのことでした。

・セッション 0 の分離

今までセッション 0 でサービスとユーザーセッションが実行されていたが、セッション 0 はサービスのみになり、ユーザーはセッション 1 以降に接続するようになりました。

そのため、サービスとのやり取りにはセッション間通信が必要になります。

これは Windows XP でもユーザーの簡易切り替え再現でき、ダイアログなどを表示してしまうサービスのような、セッション 0 にユーザーがいることが前提となっているサービスでは「対話型サービス検出」のダイアログが表示されます。

ユーザーとの対話を前提としたサービスはそもそもサービスとして不適切なつくりですので、適切に作り変えるのが本筋の対応になります。

・WRP（ウィンドウズリソース保護）

OS の領域などが Trusted Installer のみフルコントロールの権限を持ち、ローカル Administrator であっても読み取りと実行のみの権限までしか持たないようになったということです。

・設計

この時点でセッションの時間をオーバーしていたため、駆け足で以下のポイントを挙げていました。

- 必要最低限の権限で実行。

- 不要な昇格をしない、必要なときのみ昇格。

- 起動時のみ昇格可能である点に注意。

- 高い権限を必要とする処理の実行ボタンは、高い権限で動作させるアプリケーション内に作る。

最後のは、低い権限のアプリケーション内に高い権限のアプリケーションの起動ボタンを作った際に、必ず高い権限のアプリケーションは起動後すぐに実行処理を行うのではなく、必ずユーザ操作をはさむということです。

なぜなら低い権限のアプリケーションはマルウェアからウィンドウメッセージでボタン押下ができてしまうため、実行ボタンを用意することでマルウェアから直接実行処理を行わせないようにします。

資料が無く、また私の苦手分野（もっぱら ASP.NET や XP 向け Windows フォームが中心）のため、あやふやな記述が多くなってしまいました。

●最後に

1 日の無料セミナーとしては、かなり勉強になりました。

参加してみてよかったと思います。

ただ、初物ということで技術的に深く触れるというよりは機能紹介が多く、その点は技術者の端くれとして物足りなさも多く感じるところがありました。