セキュリティ ウォッチACL 管理用ツール
Jesper M. Johansson
Windows では、アクセス制御リスト (ACL) を使用して、ユーザーやプロセスから、ファイルやフォルダなどのリソースを使用する権限を極めて細かく制御できます。ACL の管理は、ユーザーのシステムのセキュリティ保護に関連する複雑な作業の 1 つです。さいわい、便利なユーティリティが多数あります。
こうしたユーティリティは、アクセス許可や ACL に関連する作業の自動化や簡素化に役立ちます。
ほとんどの読者は、古くからある cacls.exe ツールを使い慣れています。このツールは、Windows NT® で最初に同梱され、それ以降すべてのバージョンに付属しています。Windows Vista™ で cacls.exe を実行すると、次のメッセージが表示されます。
Microsoft Windows [Version 6.0.5744]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.
C:\Windows\system32>cacls
NOTE: Cacls is now deprecated, please use Icacls.
マイクロソフトは、Windows Vista の ACL に対する更新 (これについては、2007 年 6 月号の TechNet Magazine (technetmagazine.com/issues/ 2007/06) で説明しました) に加え、ACL の管理に使用するツールもいくつか更新しました。興味深いことに、この中で最も大きく更新されたのがコマンド ライン ツールです。
icacls.exe は Windows Vista で新たに導入されました (やや機能の低いバージョンが Windows Server® 2003 Service Pack 2 にも含まれています)。icacls.exe は最終的には cacls.exe に置き換わる予定です。お気付きかもしれませんが、このツールは更新が不完全で、Windows® 2000 で導入されたきめ細かなアクセス許可をサポートしなかったため、約 7 年も遅れた更新となってしまいました。
驚くことに、cacls.exe は廃止予定であるにもかかわらず、実際にはいくつかの新機能を含んでいます。まず、接合ポイントとシンボリック リンクの両方を認識し、これらを詳しく調査できます。次に、セキュリティ記述子定義言語 (SDDL) 文字列を使用して ACL の出力と設定の両方を実行できます。
ただし、cacls.exe が更新されたとはいえ、実際には、icacls.exe に含まれる機能が必要です。
ACL の保存と復元
過去 10 年間 (少なくとも私は)、後日復元できるように ACL を保存する機能を待ち望んできました。これは、ACL に対して実行できる最も複雑な操作の 1 つになります。ある特殊な場合を除いて、そもそも ACL が壊れていなかった元の状態に正確に戻せる可能性はほとんどありません。それでも、この機能は非常に役に立つ可能性があります。
ACL の保存や復元の方法を詳しく説明する前に、まず、これがなぜそんなに難しいかを説明しましょう。たとえば、ある地方大学に学生のユーザー データを含む階層があるとします。2 月 1 日に ACL を保存しましたが、4 月 17 日に、ACL がどういうわけか壊れていることに気付いたので、保存したコピーから復元するとします。この操作に何か複雑な点はあるでしょうか。
まず、新学期は 4 月 2 日に始まりました。学生の約 15% が卒業したため、卒業した学生のディレクトリはもう存在しません。したがって、バックアップ ファイルには、無効な ACL があります。また、新学期から、新入生の一団 (15%) も入学してきました。新入生にはホーム ディレクトリが用意されましたが、バックアップ ファイルには ACL がありません。彼らの ACL はどうしましょう。当然、70% の学生はまだ在籍していますが、彼らは新しいファイルやフォルダの作成や、ファイルやフォルダの削除を行っています。削除されたファイルやフォルダは無視できますが、新しく作成したフォルダはどのように構成すればよいでしょうか。学生が 3 月 4 日に友人とフォルダを共有していた場合はどうなるのでしょう。ACL を復元するときに、共有が解除されてもかまわないでしょうか。
ACL の保存と復元は、多くの人が思っているほど簡単に実行できる操作ではありません。このような操作を行う場合は、慎重に進める必要があります。結果として、不明確な動作を行うことになる可能性もあります。間違いなく、ACL の復元は最後の手段です。バックアップしてから時間が経つほど、復元時に何かが機能しなくなる可能性が高くなります。
それでもこの機能を使用する場合は、/save スイッチを使用して icacls.exe を実行します。
icacls <target> /save acls.bin /t
これにより、ACL は acls.bin というファイルに保存されます。ファイルには、ACL が設定されたオブジェクトごとに 1 行、その後、SDDL で ACL を指定する 1 行が含まれます。/t スイッチを使用すると、指定したオブジェクトと、そのオブジェクトの下にあるすべてのオブジェクトとコンテナを対象にコマンドが機能します。
保存機能がツールキットに加わったのは喜ばしいことですが、この機能にはいくつか欠陥があります。たとえば、システム アクセス制御リスト (SACL) ではなく、随時アクセス制御リスト (DACL) のみが保存されます。実際、SACL があると、このことを示すダミー値は保存されますが、SACL のどの部分も保存されません。
また、ACL の保存方法から、興味深い問題が生じています。保存した ACL をお気に入りのテキスト エディタで開く際は、次のことを忘れないようにしてください。
保存した ACL は編集しないでください。
保存した ACL を含むファイルをテキスト エディタで開くと、一見 Unicode (UTF-16) 形式のテキスト ファイルのように見えます。実際、ほとんどテキスト ファイルです。そのため、テキスト エディタで ACL を編集および保存できると考えがちです。しかし、このような操作は行わないでください。
保存した ACL が含まれるファイルをテキスト エディタで開いてから保存すると、そのファイルから ACL を復元できなくなります。結局、実際には Unicode テキスト ファイルではなかったことがわかります。Unicode テキスト ファイルは、2 バイトの 0xfffe で始まらなければなりません。メモ帳などのテキスト エディタでファイルを保存すると、実はこのフラグがファイルの先頭 2 バイトに設定されます。しかし、icacls.exe ツールでは、ACL データがファイルのバイト 0 の位置から始まると想定しています。その結果、先頭 2 バイトも操作対象のオブジェクトを示す文字列の一部であると見なされ、ファイル内の ACL を解析できず、バックアップ ファイルが使用できなくなります。
マイクロソフトではこの問題を認識していますが、Windows Vista のベータ期間終了間際に報告されたため、リリース前にこの欠陥を修正できませんでした。現時点では、いつ修正するか、さらには修正するかどうかもわかりません。したがって、今のところ、保存した ACL は編集しないことをお勧めします。編集が必要な場合は、ファイルを .bin ファイルとして保存して、 (お好みの開発環境などの) 16 進エディタを使用してください。
/save スイッチを使用して ACL を保存したら、/restore スイッチを指定して icacls.exe を実行し、ACL を復元できます。最も単純な形式の復元コマンドは、次の構文を使用します。
icacls <directory> /restore acls.bin
復元手順は、ファイル単位には機能しません。これを確認するために、図 1 に示す一連のコマンドをご覧ください。ここでは、1 つファイルを対象に icacls.exe を実行して、保存ファイルを作成しています。その後、/save を /restore に置き換えて、そのファイルを復元します。この操作は失敗します。それは、復元コマンドがディレクトリのみで機能するためです。復元対象のファイルは、acls.bin ファイル内に既に指定されています。ACL を復元するには、ファイルではなくディレクトリを指定します。これは最後のコマンド行で行っており、操作対象のオブジェクトに "." を指定します。
Figure 1 ACL の保存と復元
C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files
C:\Users\Jesper>icacls test.txt /restore acls.bin
test.txt\test.txt: The system cannot find the path specified
Successfully processed 0 files; Failed processing 1 files
C:\Users\Jesper>icacls . /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files
復元コマンドは権限を昇格して実行する必要があることにも注意してください。保存コマンドは、ACL の読み取り権限さえあれば、権限の低い管理者や標準ユーザーで実行されているコマンド プロンプトからも実行できます。ただし、ACL を復元するには、完全な管理トークンが必要です。
SID の置き換え
icacls.exe の非常に便利なもう 1 つの機能に、あるユーザーのアクセス許可を別のユーザーのアクセス許可に置き換える機能があります。この置き換えは、復元時に /substitute スイッチを使用して行います。substitute スイッチに関するドキュメントでは、このスイッチには SID が必要であると記載されていますが、後から、実際には通常のユーザー名も指定できると説明されています。したがって、図 2 に示すシーケンスが機能します。
Figure 2 復元時の SID の置き換え
C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\foo:(R,W)
VistaRC2-Test\Jesper:(I)(F)
NT AUTHORITY\SYSTEM:(I)(F)
BUILTIN\Administrators:(I)(F)
Successfully processed 1 files; Failed processing 0 files
C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files
C:\Users\Jesper>icacls. /substitute foo bar /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files
C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\bar:(R,W)
VistaRC2-Test\Jesper:(I)(F)
NT AUTHORITY\SYSTEM:(I)(F)
BUILTIN\Administrators:(I)(F)
Successfully processed 1 files; Failed processing 0 files
ご覧のとおり、結果として以前と同じ ACL になりますが、foo のアクセス許可を指定するのに使用された ACE は、代わりに bar のアクセス許可を指定するようになります。
所有者の変更
UNIX システムでは主に、chown ツールが長い間使用されてきました。本来、Windows には、オブジェクトの所有者を変更する方法は組み込まれていませんでした。その後、setowner ツールがリソース キットに組み込まれ、takeown.exe ツールが Windows NT 4.0 に組み込まれました。ただし、このユーティリティを使用しても所有権を得ることしかできず、相手のパスワードを知らない限り、所有権を他のユーザーに付与することはできませんでした。icacls.exe には、所有者を設定できるアクセス許可が与えられているオブジェクトの所有者を設定する機能が組み込まれるようになりました。
C:\>icacls c:\test /setowner foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
残念ながら、icacls.exe ではオブジェクトの所有者を表示できません。実際には、コマンド ラインからオブジェクトの所有者を表示する方法はありません。さらに、オブジェクトの ACL を保存しても、オブジェクトの所有者は保存されません。
icacls.exe にも、所有者を変更する際に SeTakeOwnershipPrivilege を呼び出さないというバグがあります。ACL に基づいてオブジェクトの所有者を変更する権限があれば、icacls.exe は通常どおり機能します。ただし、管理者であっても、オブジェクトの ACL に基づいて所有者を変更するアクセス許可がなければ、このバグが原因で、この操作に icacls.exe を使用することはできません。その場合は、takeown.exe ツールを使用する必要があります。このツールからは SeTakeOwnershipPrivilege を呼び出しますが、任意のアカウントではなく、使用中のアカウントまたは Administrators グループに所有者を変更することしかできません。
C:\>takeown /f c:\test
SUCCESS: The file (or folder): “c:\test” now owned by user “JJ-VistaRTMTst\Jesper”.
当然ながら、subinacl ツール (Microsoft ダウンロード センターからダウンロード可能) にも setowner スイッチがあることに注意してください。実際、多くの場合 subinacl は icacls よりも直感的に機能しますが、使用はさらに複雑になります。
特定のユーザー向けファイルの検索
icacls には、他にも便利な機能があります。特定のユーザーにアクセスが許可されたファイルを検索できます。以下に例を示します。
C:\windows\system32>icacls “c:\program files” /findsid jesper /t
SID Found: c:\program files\Passgen\
passgen.exe.
Successfully processed 1808 files; Failed processing 0 files
これは、特定のユーザーがアクセスできるファイルを確認する場合に役立ちます。
ACL のリセットと変更
ACL が破損した場合や破棄された場合、icacls.exe では、親から継承するように ACL をリセットできます。これは、2006 年秋に発生したゼロデイのセキュリティ問題で非常に役立ちました。Windows コンポーネントでの問題を緩和するために使用された方法の 1 つは、オブジェクトに対する Everyone のアクセス許可を拒否することでした。拒否することは容易でしたが、Windows XP や Windows Server 2003 の組み込みツールを使用しても、そのアクセス制御エントリ (ACE) を削除することはほぼ不可能でした。しかし、Windows Vista では、次のコマンドを実行するだけでリセットできます。
C:\windows\system32>icacls “c:\program files\passgen\passgen.exe” /reset
processed file: c:\program files\passgen\passgen.exe
Successfully processed 1 files; Failed processing 0 files
もちろん、icacls.exe では、標準の許可、拒否、削除の操作すべてを行うことができます。これらの操作のうち、実際に新しいのは、削除だけです。このスイッチを使用すると、特定のオブジェクトや階層から、指定したユーザーのすべての許可 ACE、すべての拒否 ACE、またはその両方を削除できます。許可、削除、および拒否の各操作の例を図 3 に示します。
Figure 3 許可、拒否、および削除の操作
C:\>icacls c:\test /grant foo:(F)
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(F)
BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test /remove:g foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test /deny foo:(F)
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(N)
BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test /remove:d foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
Successfully processed 1 files; Failed processing 0 files
拒否 ACE のみを削除する機能は、特定のグループやユーザーまで、オブジェクトのアクセスを許可する場合に役立ちます。
整合性レベルの設定
icacls.exe には、整合性レベルを表示および設定する機能もあります。Windows Vista では、オブジェクトへの整合性ラベルの設定がサポートされます。icacls.exe は、この操作に使用するコマンド ライン ツールです。
C:\>icacls c:\test /setintegritylevel high
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
Mandatory Label\High Mandatory Level:(NW)
Successfully processed 1 files; Failed processing 0 files
icacls.exe は、オブジェクトに整合性ラベルが明示的に設定されている場合にそのラベルを表示するだけです。ほとんどのファイルには明示的に設定されていないため、表示されることはめったにありません。
最後に、icacls.exe では、オブジェクトに正規の ACL があることを確認できます。既に説明したように、サードパーティのツールでは、ACL に ACE を間違った順序で配置することがわかっています。icacls.exe では、次に示すように、こうした問題を確認して修正できます。
C:\>icacls c:\test /verify
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
ACL UI
ACL UI (ACL ユーザー インターフェイス) は、Windows XP から多少変更されました。Windows XP と Windows Vista の ACL UI のダイアログを、それぞれ図 4 と図 5 に示します。
図 4** Windows XP の ACL UI ダイアログ **
図 5** Windows Vista の ACL UI ダイアログ **
ご覧のように、いくつか変更点があります。まず、ダイアログでは、最終的に、操作対象となるオブジェクトが非常に明確に表示されます。これは、同時に複数のオブジェクトを操作している場合に役立ちます。次に、一番下に関連情報へのハイパーリンクがあります。しかし、最も注目すべき変更は、[追加] ボタンと [削除] ボタンがなくなったことです。これら 2 つのボタンが [編集] ボタンに置き換わっています。[編集] ボタンは、主に Windows Vista のユーザー アクセス制御 (UAC) をサポートするためにあります。ボタン上に盾が表示されていることからわかるように、このダイアログを起動したユーザーは、ACL を編集するアクセス許可がないため、アクセス許可を編集するには、権限を昇格する必要があります。C: ドライブのルートにフォルダを作成した直後にプロパティを確認すると、盾が表示されないことに注意してください。フォルダの所有者であれば、ACL を編集する暗黙のアクセス許可があるため、盾が表示されません。盾は COM モニカを表します。COM モニカは、実行中のプロセスの一部に対して権限の昇格を問い合わせるプロンプトを表示するために使用されるメカニズムです。[編集] をクリックすると、なじみのある昇格ダイアログが表示されます。昇格ダイアログで [続行] をクリックすると、Windows XP で [追加] をクリックしたときに表示されるのとほぼ同じダイアログが表示されます。ACL UI は複数の局面でこうした 2 種類のダイアログの概念に従っています。権限の昇格が行われるまでは 1 つのダイアログを表示し、昇格が行われると、以前のバージョンの Windows の使い慣れた古いダイアログが表示されます。
[詳細設定] をクリックして [監査] タブをクリックすると、図 6 に示すように、権限の昇格を必要とするボタンが必ず表示されます。オブジェクトのフル コントロール権限を持っていたり、そのオブジェクトの所有者であっても、権限を昇格しないと監査を変更できません。これは、オブジェクトの SACL を変更する権限が SE_SECURITY_NAME 特権によって管理されているためです。この特権は、GUI ツールでは "監査とセキュリティ ログの管理" と表示されます。既定でこの権限があるのは管理者だけです。ただし、(UAC が有効な場合に) 管理者承認モードで管理者からこの特権が削除されると、管理者であっても、権限の昇格が必要になります。
図 6** Windows Vista で監査設定を変更する場合は常に権限の昇格が要求される **
ACL を変更する際に必要な権限の昇格について、最後の注意点です。それは、ここに記載した内容はすべて、UAC を無効にしていないことが条件であるという点です。UAC を無効にすると、ダイアログの見た目が異なることを除き、すべての動作が Windows XP の動作に戻ります。ただし、トークンには常に Administrators の SID が含まれるようになるため、管理者としてログオンした場合、権限の昇格は必要ありません。
その他のツール
icacls.exe は、cacls.exe を根本から改良した、非常に有益なツールですが、まだいくつか欠点があります。おそらく、ファイルとディレクトリ以外のオブジェクトへのアクセス許可を管理できないことがその代表です。Windows Vista でのその他のオブジェクトの ACL への変更は、Windows XP に比べればあまり行われていませんが、サービス、レジストリ キー、または Active Directory® オブジェクトの ACL の管理が必要になることもまだまだあります。
コマンド ラインの愛好家であれば、この操作には subinacl.exe が必要です。subinacl.exe は、サポート ツールに含まれています。また、ダウンロードすることもできます。
ただし、断っておきますが、subinacl.exe の使用は簡単ではありません。実際、まったく役に立たない場合もあります。一方、アクセス制御を管理する場合は実に強力なツールです。すべての管理者は、このツールを必要とします。
レジストリの ACL
レジストリの ACL は、ファイル システムの ACL とまったく同様に変更が行われました。ただし、この変更は、ファイル システムへの変更ほど範囲は広くありません。以前のバージョンの Windows との最も明確な違いは、Power Users の廃止により、ほとんどすべての Power User ACE がなくなったことです。Power Users は、他のユーザーよりも強力であるべきではありません。ただし、Power Users のすべての ACE が実際になくなるわけではないため、ACL が実際にいかに複雑になったかを証明するにすぎません。残念なことに、いくつかは残ってしまいました。
レジストリの ACL を見ていくと、いくつかの場所に RESTRICTED という SID の ACE があるのが確認されます。これは、Windows Vista で新しく導入された SID ではありませんが、十分に理解されていない、興味深い SID です。RESTRICTED SID は、制限付きトークンを提示するプロセスを示します。制限付きトークンは、CreateRestrictedToken API の特殊な機能を使用して作成されます。このようなトークンでは、1 つ以上の SID を制限します。これらの SID は、個別のアクセス チェックに使用されます。たとえば、制限付きトークンで実行されているプロセスがあるとします。そのプロセスから RESTRICTED SID の ACE を備えたオブジェクトにアクセスを試みると、実際には、Windows で 2 つのアクセス チェックが実行されます。まず、通常のアクセス チェックが行われます。次に、最初のアクセス チェックとまったく同様に機能しますが、トークンで制限している SID のみに対してアクセス チェックを行います。両方のアクセス チェックに合格する必要があります。
現状では、特にレジストリに、RESTRICTED SID を使用する ACL が複数あります。図 7 に、こうした ACL のスクリーン ショットを示します。
図 7** レジストリの ACL で RESTRICTED の ACE を複数の場所に含める **
現時点では、特に SID を制限することに関して、制限付きトークンの機能を使用するプロセスはほとんどありません。実行するプロセスの一例として、Windows ファイアウォール、ベース フィルタ エンジン、および診断ポリシー サービスをホストするサービス プロセスがあります。このプロセスでは、書き込み制限付きのトークンも使用します。調べたところ、Windows Vista では、現在、9 個のサービスのみで、RESTRICTED トークンと書き込み制限付きトークンを使用しています。
以前のバージョンの Windows と同様に、レジストリのアクセス許可に関するベスト プラクティスは、慎重に進めます。例外的な状況や対象を限定する場合を除いて、レジストリのアクセス許可は変更しないでください。複雑な継承モデルや注意を要する操作がレジストリで実行された場合に、そのレジストリの ACL を不注意に変更すると、致命的なエラーが受け入れがたいほど高い確率で発生します。
まとめ
Windows のほとんどのバージョンと同様に、Windows Vista でもアクセス制御が少し変更されています。ただし、他のいくつかの最新バージョンとは異なり、最終的には動作の大幅な変更につながる、小さな変更が数多く行われています。特に、UAC は、整合性ラベルや ACL UI の変更など、複数の変更が必要でした。さらに、これまでの記録上初めて ACL が大幅に整理されました。
多くの点で、Windows の既定の ACL が Windows Vista で簡略化されました。このようなことは今まで一度もありませんでした。ただし、これまでのバージョンと同様に、アクセス制御については十分に理解するまで、慎重に扱う必要があります。このことは、特に新しいバージョンの OS で当てはまります。このコラムで説明したツールを使用することで、ACL の調査が楽になるとよいのですが。
Jesper M. Johansson は、ソフトウェアのセキュリティ問題に取り組む Principal Security Engineer で、TechNet Magazine の編集にも携わっています。MIS の博士号を持ち、コンピュータ セキュリティの分野で 20 年以上の経験があります。このコラムは、Roger Grimes と Jesper Johansson が共同で執筆した新しい書籍『Windows Vista Security: Securing Vista Against Malicious Attacks』(Wiley、2007 年刊) から引用したものです。
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.