web-dev-qa-db-ja.com

Security Eventlogレジストリキーのアクセス許可をIT運用に変更するリスクは何ですか？

背景

多くの開発者は、不必要にイベントログのセキュリティを下げたり、このC＃またはVBコードでイベントログを使用できるようにするために、アプリケーションを管理者モードで実行するように要求しています。

  EventLog.[WriteEntry][1]("MyBadApp", "This will cause an exception for ASP.NET and non admins", EventLogEntryType.Error, 10);

.. "MyBadApp"に必要なレジストリキーを作成するインストーラを作成しない

詳細情報

これをNetwork Service、ASP.NET、WCF、サービスアカウントで実行し、管理者以外のアカウントを使用している場合、次の例外が発生します...しかし、ログが記録されるかどうか、または記録される場所はだれですか（Googleのために貼り付け）

System.Security.SecurityException: The source was not found, but some or all event logs could not be searched.  Inaccessible logs: Security.
   at System.Diagnostics.EventLog.FindSourceRegistration(String source, String machineName, Boolean readOnly)
   at System.Diagnostics.EventLog.SourceExists(String source, String machineName)
   at System.Diagnostics.EventLog.VerifyAndCreateSource(String sourceName, String currentMachineName)
   at System.Diagnostics.EventLog.WriteEntry(String message, EventLogEntryType type, Int32 eventID, Int16 category, Byte[] rawData)
   at System.Diagnostics.EventLog.WriteEntry(String source, String message, EventLogEntryType type, Int32 eventID, Int16 category, Byte[] rawData)
   at System.Diagnostics.EventLog.WriteEntry(String source, String message, EventLogEntryType type, Int32 eventID)
   at **YOUR.CUSTOM.BROKEN.CODE.HERE(ResolvedMessageEventSource source, QueuedMessageEventArgs e) in c:\test2\YourProjectHere\Class1.cs:line 116**

 ----  SNIP Possibly more stuff here --
System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(_ThreadPoolWaitCallback tpWaitCallBack)
   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state)
The Zone of the Assembly that failed was:
MyComputer

マイクロソフトはこの問題を認識していますが、迅速かつダーティーなEventLogアクセスのための 仕様 です。 WriteEntry が呼び出されるたびに、システムはレジストリを列挙し、アプリケーションが指定した「ソース名」を探します。存在しない場合は作成されます。

問題は、列挙中にセキュリティログがヒットし、例外がスローされることです。インストーラーを作成しない、または「MyBadApp」のレジストリキーを作成しない開発者は、動的イベントの作成にフォールバックし、この問題が発生します。

これは仕様によるものであり、 WriteEntry に影響しますが、頻度は低くなります WriteEvent （WriteEvent開発者は通常、インストーラーを作成します）

ソリューション

私が知っている3つの解決策があります：

  1. アプリケーションを管理者として実行する（悪い）

  2. レジストリキーのアクセス許可を変更する

  3. アプリケーションのレジストリキーを作成するインストーラーを作成する（最適なソリューション）

質問

Security Registryキーのアクセス許可を変更するアプリケーションで起こり得る最悪の事態は何ですか？

  • セキュリティイベントログを読み取ることができますか？

  • セキュリティイベントログのエントリを変更または変更できますか？

  • 独自のものではないセキュリティイベントを偽装できますか？

  • それはDoSにつながりますか？

windowslogging.netpermissions
6
goodguys_activate

セキュリティイベントログの権限を変更しないでください。

パーミッションを変更すると、パーミッションを持つユーザーとして実行されているすべてのアプリケーションがそれを読み取ることができ、前述のパーミッションを付与している場合は、それに書き込むことができます。レジストリキーでSDDL形式を使用していることを思い出したら、それは非常に簡単に誤って設定されます。

基になるイベントログファイルへのアクセス権がない限り、読み取りまたは書き込みのアクセス許可を持つエントリを変更することはできませんが、システムによってロックされています。

はい、セキュリティイベントを偽装できます。

ログが最大サイズに達するとカーネルパニックが発生するようにログが設定されている場合、DoSに完全につながる可能性があります。

いずれの場合も、レジストリキーを直接変更してはなりません。これは、WMIまたはwevtutilのコマンドラインを使用して行う必要があります。

インストーラー（管理者ユーザー）は、アプリケーションを実行する前にログソースを作成する必要があります。ソースが存在するかどうかを確認するのは非常に簡単です：

if (EventLog.SourceExists("YourSource")) { /* do your stuff */ }

これを呼び出すことでソースを簡単に作成することもできます：

EventLog.CreateEventSource("YourSource", "YourLogName");
3
Steve