次の方法で共有

Longhorn のセキュリティ: 最小限の特権に重点を置く

  • [アーティクル]

 

Keith Brown
DevelopMentor

2004 年 4 月

適用対象:
   2003 Professional Developers Conference (PDC) "Longhorn" プレビュー ビルド

概要： Longhorn は、最小特権のアプリケーションに最適なプラットフォームであることを約束します。 まず、マネージド コードを記述して、今すぐ作業を開始します。 デスクトップ アプリケーションをビルドするときは、LUA に準拠させます (また、Windows アプリケーション検証ツールを使用して作業のチェックに役立ちます)。 (11ページ印刷)

内容

問題
アプリケーション マニフェストと配置マニフェスト
LUA: 最小特権ユーザー アカウント
(非推奨) Power Users グループ
AIM: アプリケーション影響管理
PA: 保護された管理者
Longhorn でのマネージド アプリケーション
"リスクなし" アクセス許可セット
ツール
まとめ

私は長い間、最小限の特権で実行を支持してきました。 私を知っている多くの人は、開発者がコードの開発中に管理特権を使用して実行をやめる必要があるという私の言い回しを聞いたことがあります。これは、最小限の特権環境で実行するようにより多くのアプリケーションを作成するよう促すためだけに役立ちます。 そのため、2003 年の Microsoft Professional Developers Conference (PDC) で、次のバージョンの Windows® オペレーティング システムのコードネーム "Longhorn" のメイン目標の 1 つは、ユーザーが最小限の特権で簡単に実行できるようにすることです。

問題

ローカル ソフトウェア ショップで Microsoft Windows XP® Professional のコピーを購入し、PC にインストールすると、セットアップ ウィザードによって、自分とコンピューターを使用する他のユーザーのアカウントが作成されます。 Windows XP が起動すると、各ユーザーの名前を示すかなりようこそ画面が表示され、ログインできるようになります。 これらの各ユーザーは、既定でマシンの管理者です。 なぜでしょうか。 このようにしないと、ユーザー エクスペリエンスが低下するためです。

ユーザーは自分のマシンにソフトウェアをインストールできると期待していますが、管理者でない限り、今日のソフトウェアの 90% をインストールすることはできません。 ユーザーは、ソフトウェアがクラッシュすることなく実行されることを期待していますが、ユーザーが管理者でなければ、ソフトウェアの 70% は正常に実行されず、これは楽観的な数値です。 残念ながら、これらのアプリケーションの多くが非管理環境で失敗するのは、アプリケーションの状態を保存する場所に関する選択が不十分であるからです。 Program Files ディレクトリは、状態を格納するための場所ではありません。 これは、プログラム (実行可能ファイル) を格納するための場所です。 アプリケーションの状態を格納する場所は ユーザー プロファイルと呼ばれ、共有ユーザーの状態を格納するには、"すべてのユーザー" プロファイルで十分です。 Windows ロゴ プログラムのガイドラインではこれを説明していますが、現在の Windows ソフトウェアの大部分は、Windows ロゴ ガイドラインを考慮せずに開発されました。

しかし、ユーザーが管理者以外、特にホーム ユーザーとして実行する必要がある理由は何でしょうか。 実際に行うのが簡単であれば、ホーム ユーザーは多くの利点を得られます。 マルウェア (ウイルス、ワーム、またはその他の悪意のあるコード) には、管理特権が必要です。 最近は、Web を閲覧したり、管理者として電子メールを読んだりすることは、単なる危険です。 あなたの子供はどうですか? 誤って何かを壊したり、スパイウェアをインストールしたり、課したコンテンツ評価の制限を取り除いたりしないことを知って、ホームコンピュータにゲームをインストールしてプレイできるようにすることは良いことですか? このように考えてみましょう。管理者として実行すると、Windows によって提供されるセキュリティ保護の大部分が効果的にオフになります。 特にインターネットに接続されている場合は、ホームユーザーと企業ユーザーがこれらの保護をオフにしないでください。これはかなり危険な地域になっています。

ユーザーと実行するプログラムを最小限の特権環境で幸せに暮らすことで、Windows プラットフォームのセキュリティが大幅に向上します。

アプリケーション マニフェストと配置マニフェスト

Longhorn が導入する重要な機能の 1 つは、アプリケーション マニフェストと配置マニフェストの概念です。 前者は、アプリケーション開発者がアプリケーションが適切に機能するために必要なアクセス許可を示し、後者を使用すると、管理者はアプリケーションに置く信頼の量を指定できます。 これらのマニフェストにはこれ以上のものがありますが、マネージド アプリケーションとアンマネージド アプリケーションの両方で使用できる点と、その存在の大きな理由は、ユーザーが最小限の特権でアプリケーションを実行できるようにすることです。

これらのマニフェストの詳細については、Brent Rector の書籍 「開発者向けの "Longhorn" の概要」の第 1 章を参照してください。

LUA: Least-Privilege ユーザー アカウント

LUA ( 最小特権ユーザー アカウント) は頭字語であり、今後 Microsoft プレゼンテーションで繰り返し表示されます。 PDC 2003の発表者は、しばしば頭字語を「looah」と発音しました。それは本当に新しいものでもなく、何もファンシーではありません。 LUA とは、対話型ユーザーとサービスの両方で、特権のないユーザー アカウントを使用する方法を指します。

Longhorn チームは、セキュリティを簡素化したいと考えています。 システムへのアクセスには、最小特権と管理の 2 つのレベルが必要であると考えています。 また、Longhorn の Power Users グループ (一部のサークルでは "admin-lite" と呼ばれます) も非推奨になっています。

Power Users グループがなくなったので、アプリケーション開発者は本当に選択する必要があります。 アプリケーションで Longhorn に必要な特権 (LUA または管理) の 2 つのレベルのうちどれを決定する必要があります。 アプリケーションに管理特権が必要ない場合は、最小限の特権アカウントで動作するように慎重に記述する必要があります。 つまり、通常のユーザー アカウントを使用したテスト (および、コードの記述も望む) です。 たとえば、LUA アプリケーションでは、Program Files ディレクトリ ツリーではなく、ユーザー プロファイルなどの安全な場所にデータ ファイルを書き込む必要があります。 しかし、Longhorn 用に書き換えられていないアプリケーションはどうなりますか? Windows XP でも、これらのアプリケーションが最小特権アカウントで十分に動作しない場合はどうなりますか? Application Impact Management (AIM) と呼ばれる Longhorn 機能は、これらのアプリが LUA で実行されるのに役立つ場合があります。これについては、後ほど説明します。

(非推奨) Power Users グループ

"高い" アクセス権を持つ管理者アカウントと、"低" のアクセス権を持つ通常のユーザー アカウントを考えると、Power User アカウントは "中程度" のアクセス権を持っていると言えます。 Power Users グループは、ファイル システムとレジストリの一部 (通常は最小特権アカウント (つまり、管理者や Power Users などの特権グループのメンバーシップを保持していない通常のユーザー アカウント) の読み取りと書き込みを行うことができます。 通常のユーザーとして実行しようとした多くのユーザーは、非常に多くのソフトウェアが失敗し、自分のアカウントを Power Users グループに追加することにしました。これにより、発生していたほぼすべての問題が修正されました。 しかし、彼らはもはや最小限の特権で本当に実行されていませんでした。 たとえば、Windows XP では、この "中" レベルの特権で実行されるマルウェアは、Program Files ディレクトリに格納されている他のアプリケーションを侵害したり、信頼された COM コンポーネントをトロイの木馬に置き換えたりすることが許可されます。 次回、ユーザーがこのような侵害されたマシンで自分の管理アカウントで実行されると、以前にインストールされたトロイの木馬でもマルウェアが実行されることを確認できます。 そのため、Power User として実行されている実際の保護は取得されません。

AIM: アプリケーション影響管理

Longhorn チームは、最小限の特権で実行することが重要であると考えています。 彼らは、主に最小特権アカウントで構成されるユーザー アカウントの一覧を含むように、非常にようこそ画面を望んでいます。 しかし、彼らはまた、現実に足を接地しています。 今日の多くの主要なソフトウェアがWindowsロゴプログラムを完全に無視しているのと同様に、ロングホーンの時間枠内の多くの主要なソフトウェアもLUAイニシアチブを無視するかもしれません。 フォーム化されていないアプリケーション開発者は、Program Files ディレクトリ ツリーからデータ ファイルを読み書きするソフトウェアを引き続き記述します。 また、HKEY_CURRENT_USERではなく、レジストリ データを引き続きHKEY_LOCAL_MACHINEに書き込みます。 前者は通常のユーザーによる書き込みの制限がないため、レジストリをまったく使用する必要がある場合は、アプリケーション設定を格納する場合に後者を使用することをお勧めします。

Windows XP は、アプリケーションにさらに多くの特権が必要であることを検出できる場合 (これはまれですが、セットアップ プログラムで発生することがあります)、特権のないユーザーに対して、アプリケーションの実行に管理特権が必要であることを通知し、管理者アカウントのユーザー名とパスワードを収集するためのダイアログをポップアップ表示します。 その後、プログラムは指定されたアカウントで実行されます。 ただし、多くのアプリケーションが 1 つのアカウントにインストールされ、別のアカウントで使用されるように記述されていないため、これは常に機能するとは限りません。

ロングホーンは全く異なるアプローチを取ります。 アプリケーションが正常に機能するようにユーザーに特権を昇格させる代わりに、Longhorn は LUA でアプリケーションを実行することを好みます。 ただし、アプリケーションが HKEY_LOCAL_MACHINE または Program Files ディレクトリ ツリーに書き込もうとするとどうなりますか? Longhorn は、書き込み時のコピー戦略を使用して、変更しようとしているリソースの独自の仮想化ビューをアプリケーションに提供します。 アプリケーションが Program Files ディレクトリ内のファイルに書き込もうとすると、Longhorn はアプリケーションにファイルの独自のプライベート コピーを提供し、パーティを行うことができます。 この方法では、AIM シナリオで緩いマルウェアが発生すると、プログラム ファイル ディレクトリ ツリーの下で一般的に使用される実行可能ファイル (おそらくWINWORD.EXE) を上書きしようとする可能性があります。 しかし、最終的に上書きされるのは、マルウェアだけが見ることができるプライベートコピーです。 ユーザーに表示されるWINWORD.EXEのバージョンは、元の未保持バージョンのままです。

AIM に依存して保存しないでください。 1 日目から LUA で実行するアプリケーションを作成します。

PA: 保護された管理者

すべてのアプリケーションをLUAで実行するためにLonghornの時間枠で修正する必要があったとしても、管理特権を本当に必要とするアプリケーションはまだ存在します。 これには、バックアップ ソフトウェア、ハード ドライブの最適化と再パーティション分割ソフトウェア、エンタープライズ管理ソフトウェアなどのユーティリティが含まれており、一覧は続きます。 そのため、ある時点で、ユーザーは管理アカウントを使用して特定の作業を完了する必要があります。 それに直面してみましょう、多くの人々はLUAアカウントを作成し、単に常に管理者として実行するためのアドバイスを無視します。

Longhorn チームは、管理アカウントで実行している場合の保護に役立つきちんとしたスキームを考案しました。 これは 保護された管理者と呼ばれる機能であり、有効にすると、常に管理アカウントで実行でき、合理的に安全に感じることができます。実行するアプリケーションの大半は、LUA シナリオで持っているトークンと同様の特別な制限付きトークンで実行されるためです。 "祝福された" アプリケーション、または会社がデプロイして信頼済みとして指定したアプリケーションのみが、完全な管理トークンで実行されます。 アプリケーションを信頼済みとして指定する方法の 1 つは、その配置マニフェストに署名することです。 なぜこれが役に立つのでしょうか。 例を示します。

通常、管理者として実行されているユーザーは、Longhorn 電子メール クライアントを開き、電子メールの閲覧を開始します。 彼女は知り合いから届いたメールに出くわし、添付ファイルを開きます。 彼女は彼女の友人が最近電子メールワームに感染し、このメッセージにはマルウェアが含まれていることをほとんど知りません。 マルウェアが実行されると、システムに対する特権がほとんどないことがわかります。 Program Files ディレクトリ ツリーでは何も変更できません。 HKEY_LOCAL_MACHINEで COM オブジェクトの登録を変更することはできません。 これは悪いことはできないと言うわけではありませんが、マルウェア自体が管理者権限で実行されているのを見つけた場合よりも、状況はずっと良い状況です。

しかし、待って、私はユーザーが電子メールアプリケーションを実行したときに管理者として実行されていたと言いませんでしたか? はい、実際にはそうでした。 しかし、電子メールアプリケーションは「祝福された」管理アプリとして指定されませんでした。実際には、LUA アプリケーションとして記述されました。 したがって、制限されたトークンを受け取り、結果としてマルウェアも受け取りました。 これは、最小限の特権の全体のポイントです。 システムの制御を失った場合 (誤って何らかの悪意のあるソフトウェアを実行した場合や、間違ったメニュー項目をクリックした場合など)、損傷は制約されるか、完全に防止されます。

一部のセキュリティ意識の高い管理者は、現在このポリシーを既に実装しています。 私はそのうちの一人です。 私は通常のアカウントと管理アカウントの2つのアカウントを持っています。 通常のユーザーとしてログインし、何らかの方法でシステムを管理する必要があるときに、場合によっては管理アカウントに切り替えます。たとえば、マシンに仮想ディレクトリを追加したり、Microsoft SQL™ Server でデータベースを作成したりします。 (あなたが疑問に思っていた場合、私はソフトウェアを開発する場合でも、通常のユーザーとして実行している時間の約95%を費やします。Longhorn チームは、このアプローチを正式化しました。これは、保護された管理者 (略して PA) 機能で "適切な特権を適切なタイミングで" と呼ばれることが多いアイデアです。 これは、管理者として常に実行できるが、引き続き最小限の特権で実行できることを意味します。 2 つのユーザー プロファイルを切り替えたり、切り替えたりする必要はありません。

これがきちんとしたアイデアのように聞こえて、ユーザーがこの機能を実際に使用できるようにしたい場合は、最小限の特権で実行されるアプリケーションの作成に真剣に取り組む必要があります。 この機能が有効になっている場合、実際に必要以上の特権を必要とするアプリケーションは、信頼された管理アプリケーションとして指定されていない限り、管理者が実行しても不必要に中断されるためです。 もちろん、AIM は救助に来る可能性がありますが、それに頼ってはいけません。これは、アプリケーションの 20% が、おそらく AIM を介して LUA 互換にすることができないと Microsoft が見積もっているためです。 この 20% に該当した場合、アプリケーションの実行に失敗します。 これが十分に発生した場合、誰も保護された管理機能を使用しません。それは本当に悲しいことです。

その他の利点は、最小限の特権で実行されるより多くのアプリケーションが記述されるにつれて現れます。 たとえば、企業は最終的にワークステーションをロックダウンし、従業員が最小限の特権アカウントで実行できるようになります。 これにより、管理が大幅に簡素化され、コストが削減されます。 これまで以上に、最小限の特権で実行されるアプリケーションを作成することが重要です。 このプラットフォームで違いを生み出すことができます。

Longhorn でのマネージド アプリケーション

PDC 2003からのメッセージの1つは、マネージドアプリケーションが未来であるというものでした。 マネージド コードを記述することで、Windows プラットフォームのセキュリティにおける最新の革命であるコード ID によるセキュリティを活用できます。 共通言語ランタイム (CLR) によって提供され、多くの場合、CAS (コード アクセス) セキュリティと呼ばれる証拠ベースのセキュリティ システムを使用すると、CLR は、どこから来たか、誰が署名したかなどに基づいてコードに追加の制限を適用できます。 これにより、セキュリティの次元が追加され、ソフトウェア配布の新しい道が開かれます。 セキュリティで保護されたサンドボックスでコードを実行することで、クライアントは中央サーバーからダウンロードしたコードを自信を持って実行できるようになりました。これにより、"タッチなし" や "クリック 1 回" の展開などの機能が実現可能になり、管理コストがさらに削減されます。 また、展開とセキュリティのリスクが似ている場合、コンピューター上で実行されている実際の Windows アプリケーションをブラウザーベースのアプリケーションにしたくないのは誰ですか?

Longhorn では、各マネージド アプリケーションは、アプリケーション マニフェストを介して機能するために必要な特定のアクセス許可を示すことができます。 コード一覧 1 は、既定のウィザードで生成された "Longhorn Application" プロジェクトをビルドしたときに生成されるマニフェストの例を示しています。 TrustInfo セクションと、そこで表されるアクセス許可のセットに注意してください。 これらは、アプリケーションを実行するために必要なアクセス許可です。

コード一覧 1. アプリケーション マニフェスト

<?xml version="1.0" encoding="utf-8"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" 
manifestVersion="1.0" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="urn:schemas-microsoft-com:asm.v1 
assembly.adaptive.xsd">
  <assemblyIdentity name="MyLonghornApp" version="1.0.0.0" 
processorArchitecture="x86" asmv2:culture="en-us" 
publicKeyToken="0000000000000000" />
  <entryPoint name="main" xmlns="urn:schemas-microsoft-com:asm.v2" 
dependencyName="MyLonhornApp">
    <commandLine file="MyLonghornApp.exe" parameters="" />
  </entryPoint>
  <description asmv2:iconFile="App.ico" />
  <TrustInfo xmlns="urn:schemas-microsoft-com:asm.v2" 
xmlns:temp="temporary">
    <Security>
      <ApplicationRequestMinimum>
        <PermissionSet class="System.Security.PermissionSet" 
version="1" ID="SeeDefinition">
          <IPermission 
class="System.Security.Permissions.FileDialogPermission" version="1" 
Unrestricted="true" />
          <IPermission class="System.Security.Permissions.IsolatedStorageFilePermission" 
version="1" Allowed="DomainIsolationByUser" UserQuota="5242880" />
          <IPermission 
class="System.Security.Permissions.SecurityPermission" version="1" 
Flags="Execution" />
          <IPermission class="System.Security.Permissions.UIPermission" 
version="1" Window="SafeTopLevelWindows" Clipboard="OwnClipboard" />
          <IPermission 
class="System.Drawing.Printing.PrintingPermission, System.Drawing, 
Version=1.2.3400.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" 
version="1" Level="SafePrinting" />
          <IPermission class="MSAvalon.Windows.AVTempUIPermission, 
PresentationFramework, Version=6.0.4030.0, Culture=neutral, 
PublicKeyToken=a29c01bbd4e39ac5" version="1" 
NewWindow="LaunchNewWindows" FullScreen="SafeFullScreen" />
        </PermissionSet>
        <DefaultAssemblyRequest PermissionSetReference="SeeDefinition" 
/>
      </ApplicationRequestMinimum>
    </Security>
  </TrustInfo>
  <dependency asmv2:name="MyLonghornApp">
    <dependentAssembly>
      <assemblyIdentity name="MyLonghornApp" version="0.0.0.0" 
processorArchitecture="x86" />
    </dependentAssembly>
    <asmv2:installFrom codebase="MyLonghornApp.exe" 
hash="28c18a303c7fb7e9fe43a32b456f0932f52125a9" hashalg="SHA1" 
size="110592" />
  </dependency>
</assembly>

LUA 準拠のマネージド アプリケーションには常にこのようなセクションが含まれます。Longhorn の信頼マネージャーはこの情報を使用して、アプリケーションをマシンにインストールできるかどうかを判断します。 アプリケーションが慎重にコーディングされている場合は、信頼マネージャーが "リスクなし" のスコアを割り当てることができ、アプリケーションをすぐにインストールしてユーザーの介入なしに実行できるように、低い特権で実行できる可能性があります。 ただし、アプリケーションが要求するアクセス許可に基づいて、より危険なリスク評価をスコア付けした場合、ユーザーは、アプリケーションの潜在的な危険性を説明するダイアログが表示されます。 ユーザーは、アプリケーションのインストールと実行を許可するかどうかを選択できます。

マニフェストで前もって意図を述べるのは良いアイデアです。そうでない場合、信頼マネージャーはアプリケーションに関して最悪の事態のみを想定でき、ユーザーに表示されるリスク評価はより不吉に見えるからです。 そのため、マニフェストで必要なアクセス許可を表現することをお勧めします。 この手順は省略しないでください。

PDC 2003 で説明した調査では、ActiveX コントロールのダウンロード警告などのセキュリティ ダイアログが表示されたときに、ユーザーの 40% が常に [いいえ] をクリックしていることがわかりました。 インターネット経由でソフトウェアをユーザーに配布する場合は、Longhorn の信頼マネージャーから "リスクなし" というリスク評価を望んでいるので、アプリケーションをインストールして実行する前にユーザーにメッセージが表示されません。 そのため、ドキュメントに記載されているアクセス許可のセットが常に "リスクなし" とスコア付けされるかどうか疑問に思うかもしれません。このような定義があり、 SEE アクセス許可セットと呼ばれることが判明しました。

"リスクなし" アクセス許可セット

これは PDC 2003 で SEE (セキュリティで保護された実行環境) と呼ばれると聞いたことがあるかもしれませんが、ほとんどの人はその用語を混乱させるので、リスク のないアクセス許可セットと呼びます。 Longhorn には、Longhorn の既定の信頼マネージャーと常に "リスクなし" をスコア付けする特別なアクセス許可セットが付属しています。 アクセス許可の要件がリスクのないアクセス許可セット内に完全に含まれるアプリケーションを作成する場合は、信頼の警告をまったく表示せずにインストールして実行できます。 このセット内でのみアクセス許可が付与されているコード (少なくとも Microsoft が最初に定義しているため) は、意図的または誤ってマシンに害を与えてはなりません。

そのため、ユーザーに恐ろしいダイアログを表示せずにアプリケーションをインストールして実行する場合は、このアクセス許可セットで許可されているアクティビティに制限する必要があります。 Longhorn チームは、管理者がこのアクセス許可セットを構成可能にすることを検討しているので、あるサイトで "リスクなし" と見なされるものが別のサイトで異なる可能性があることを知っている必要があります。 しかし、Longhorn インストールの大部分では、リスクのないアクセス許可セットが、オペレーティング システムに付属する既定のアクセス許可セットになります。

どのような外観ですか? コード一覧 1 のマニフェストをもう一度見てみましょう。 TrustInfo セクション "SeeDefinition" で定義されている PermissionSet に指定された ID をメモします。

PDC 2003 プレビュー ビルドのリスクなしのアクセス許可セットは次のようになります。Unrestricted FileDialogPermission を使用すると、標準の OpenFileDialog クラスと SaveFileDialog クラスを使用してユーザーが選択したファイルを読み書きできますが、ユーザーが選択したファイルの名前など、ユーザーのファイル システムの構造については何も学習できません。 IsolatedStoragePermission を使用すると、ファイル ダイアログを表示することなく、ユーザーのハード ドライブで最大 5 メガバイトのユーザー固有の状態をアセンブリで読み取りおよび書き込みできます。 SecurityPermission を使用すると、コードを最初に実行できます。 UIPermission を使用すると、画面に描画できますが、独自のウィンドウでのみ描画でき、クリップボードへのアクセスが制限されます (プログラムでその内容を読み取ることはできませんが、ユーザーはクリップボードからコントロールに貼り付けることができます)。 PrintingPermission を使用すると印刷できますが、印刷ダイアログで印刷を行う場合にのみ使用できます。 コードでは、ユーザーが行っていることをユーザーが知らなければ、印刷ジョブをサイレント モードで開始することはできません。 "Avalon" 固有のアクセス許可を使用すると、オペレーティング システムによって制御される境界線がある限り、コードで全画面表示ウィンドウを作成できます (たとえば、ログイン画面をスプーフィングすることはできません)。

この定義は、時間の経過と同時にほぼ確実に変化します。それはロングホーンベータ船の前に変更される可能性があります。 だから、塩の粒でここで私の説明を取る。 この記事は、分離ストレージや一般的なダイアログなど、.NET Frameworkの最小特権機能の一部を見始める動機として役立ちます。これは、リスクのないアクセス許可セットの最終的な定義では、信頼ダイアログを回避するためにこれらの機能を使用する必要がある可能性が非常に高いためです。

リスクのないアクセス許可セットを定義することは、簡単な作業ではありません。 Longhorn チームは、定義が制限されすぎると、十分なアプリケーションでそれを使用できないことを認識しています。 しかし、それがあまりにも制限的な場合、マルウェアは間違いなくそれを悪用します。 チームがスイートスポットを見つけることができることを願っています。 図 1 は、祝福された管理アプリケーションから、SEE アクセス許可セットで実行するように設計されたアプリケーションまで、Longhorn アプリケーションの特権の範囲を示す図です。

Aa480194.leastprivlh01(en-us,MSDN.10).gif

図 1. アプリケーションの種類

ツール

最小限の特権のアプリケーションの構築は簡単ではありませんでした。 役立つガイドラインとツールが必要です。 PDC 2003 では、これらのツールの例をいくつか見ました。その 1 つ目は Visual Studio® 2005 (PDC 2003 の時間枠では"Whidbey" というコード名) です。

この新しい開発環境には、最小限の特権環境を簡単にターゲットにするのに役立つ多くの機能が用意されています。 たとえば、アプリケーションをデバッグするときに適用するアクセス許可セットを選択できます。 Longhorn アプリケーションを開始するのに最適な場所は、SEE アクセス許可セットです。 既存のアプリケーションの場合は、インターネットアクセス許可セットをターゲットにすることをお勧めします。これは、現在の SEE の定義方法にかなり近いです。

アクセス許可を減らしてデバッグを開始すると、予期しない SecurityException が発生することが確実になります。 図 2 は、開発者がファイル ダイアログを使用してユーザーにファイル名の入力を求め、指定されたファイル名の読み取りを試みる従来の例を示しています。 FileDialogPermission が付与されている場合 (SEE アクセス許可セットに含まれている場合)、ユーザーにファイルの入力を求められますが、ユーザーが選択したファイル名の表示は特に禁止されています。 代わりに、メソッド (OpenFile) を呼び出して、ファイルから読み取るために使用できるストリームを開く必要があります。 Visual Studio 2005 では、開発者が OpenFileDialog クラスを使用してセキュリティ例外を回避する正しい方法を見つけるのに役立つアドバイスを提供します。

Aa480194.leastprivlh02(en-us,MSDN.10).gif

図 2. ツールのサポートの向上

PDC 2003 で発表されたもう 1 つの便利なツールは、PermCalc と呼ばれます。 これは、アセンブリを評価し、実行する必要があるアクセス許可をヒューリスティックで決定するコマンド ライン ツールです。 この機能は、Visual Studio 2005 にも含まれる予定です。 これは、最小特権環境をターゲットにする優れた方法です。 現在存在する同様のツールは、Windows アプリケーション互換性ツールキットの一部である Windows アプリケーション検証ツールと呼ばれます。 このツールは、アプリケーションがファイル システムまたはレジストリの保護された部分への書き込みなどの規則に違反したことを検出するのに役立ちます。

まとめ

Longhorn は、最小限の特権のアプリケーションに最適なプラットフォームであることを約束します。 まず、マネージド コードを記述して、今すぐ作業を開始してください。 デスクトップ アプリケーションをビルドするときは、LUA に準拠させます (また、Windows アプリケーション検証ツールを使用して作業のチェックに役立ちます)。 可能であれば、今のところインターネットのアクセス許可セットをターゲットにすれば、Longhorn が出荷されたときには SEE に収まる可能性があります。

詳細情報

Brent Rector の書籍 「開発者向けの "Longhorn" の概要」をお読みください。

 

筆者について

Keith Brown は、アプリケーション セキュリティを専門とする独立したコンサルタントです。 プログラミングWindows セキュリティ(Addison-Wesley、2000年)を執筆し、.NET プログラマー向けの新しいセキュリティブックを執筆しています。 オンラインで新しい本 http://www.develop.com/kbrownを読みます。