トップ回答者
イベントログのアクセスセキュリティ

質問
-
Windows Server 2003 から、イベントログのレジストリに CustomSD 値を作成することで、イベントログへのアクセスを制御できるようになりました。
http://support.microsoft.com/kb/323076/ja
このページの例を見ますと、
(D;; 0xf0007;;;AN)
という記述がありますが、イベントログに対して0xf0000というアクセスマスクはどういう意味を持っているのでしょうか?
よろしくお願いします。
回答
-
SDDLで指定されたDELETE、READ_CONTROL、WRITE_DAC、WRITE_OWNER の各フラグが
どこに作用するか、ということですね。
CustomSD中に指定されたStandard Access Maskが作用する対象についてはドキュメントに
見当たらないようです。MSDN blog等も、CustomSDについての記事については何点か
触れたものがありましたが、同様、問題のマスクについて触れられたものは無いようです。
レジストリ操作関数を用いてイベントログレジストリキーを操作する場合、それは単なるレジストリ
キーに過ぎず、その中にCustomSD値があるからといって、レジストリ操作に影響を及ぼすことは
無いのではないでしょうか?
こちらについて確認してみましたが、バッチリ?消せてしまいました。イベントログの
種類(Application等)や、その下のサブキーも削除できました。
確認を行ったのはAdministratorで、(D;;0xF0007;;;BA)が指定された状態での下です。
(=至って普通のレジストリ削除、という感じでした)
以下の感じで組んでいます。
1. CRegKeyでHKEY_LOCAL_MACHINEをオープン
2. SYSTEM\CurrentControlSet\Services\Eventlog\XXXをオープン
3. RecurseDeleteKey()でサブキーを削除
0xf0000が指定されているのが、"AN", "BG", "SY"であることからFull Access (Allow or Deny)で
あることを強調するための慣習的なものだと妄想したいのですが・・・
# ドメイン環境で作用するとか、そんな都合のいい動作は無いですよね・・・
-
ちゃっぴ@ACL オタクです。
参照すべき document は下記ですね。
Service Security and Access Rights[追記]
あれ、資料が違っていた。上記は service ですね。ただ、原理は一緒だと思うんだけどなぁ~。
Service にしろ event log でも ACL は reistry に書き込まれるわけで、READ_CONTROL にしろ WRITE_DAC にしろそんなものは関係なく対象の registry key で ACL が許可されていれば対象の registry value は読み取れるわけです。Standard Access Rights は service の場合と同じくそれを制御する GetSecurityInfo のような API を通じての処理のみ生かされるのでしょう。
ただ、現状では event log の ACL が見当たらないんですよね。もしあるとしたら、advapi32.dll に実装されているんじゃないかと思いますが、無さそうな感じです。
そうなると event log では Standard Access Rights 自体が event log では現状 reserved 扱いなんじゃないかと。
推測ですが。[/追記]
すべての返信
-
資料を見た限りですが、以下のURLが参考にならないでしょうか?
>> Access Mask Format
> http://msdn2.microsoft.com/en-us/library/aa374896(VS.85).aspx
>> Standard Access Rights
> http://msdn2.microsoft.com/en-us/library/aa379607(VS.85).aspx
>> Security Descriptor String Format
> http://msdn2.microsoft.com/en-us/library/aa379570.aspx
>> セキュリティ設定を記述するSDDL文字列とは?
> http://www.atmarkit.co.jp/fwin2k/win2ktips/725sddl/sddl.html
-
レスありがとうございます。
0xf0000 が STANDARD_RIGHTS_REQUIRED であることは承知しております。
これは、DELETE、READ_CONTROL、WRITE_DAC、WRITE_OWNER の OR ですね。
しかし、イベントログ自体に対する DELETE とは、イベントログレジストリキーの削除に相当するでしょうし、
READ_CONTROL、WRITE_DAC、WRITE_OWNER は、CustomSD 値自体の読み込み、書き込みに相当します。
これらの操作は、イベントログレジストリキー自体のアクセス許可によって設定されるものだと思います。
レジストリ操作関数を用いてイベントログレジストリキーを操作する場合、それは単なるレジストリキーに過ぎず、
その中に CustomSD値があるからといって、レジストリ操作に影響を及ぼすことは無いのではないでしょうか?
帰宅したら試してみます。
※イベントログレジストリキーとは、
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\XXX
のことです。
-
SDDLで指定されたDELETE、READ_CONTROL、WRITE_DAC、WRITE_OWNER の各フラグが
どこに作用するか、ということですね。
CustomSD中に指定されたStandard Access Maskが作用する対象についてはドキュメントに
見当たらないようです。MSDN blog等も、CustomSDについての記事については何点か
触れたものがありましたが、同様、問題のマスクについて触れられたものは無いようです。
レジストリ操作関数を用いてイベントログレジストリキーを操作する場合、それは単なるレジストリ
キーに過ぎず、その中にCustomSD値があるからといって、レジストリ操作に影響を及ぼすことは
無いのではないでしょうか?
こちらについて確認してみましたが、バッチリ?消せてしまいました。イベントログの
種類(Application等)や、その下のサブキーも削除できました。
確認を行ったのはAdministratorで、(D;;0xF0007;;;BA)が指定された状態での下です。
(=至って普通のレジストリ削除、という感じでした)
以下の感じで組んでいます。
1. CRegKeyでHKEY_LOCAL_MACHINEをオープン
2. SYSTEM\CurrentControlSet\Services\Eventlog\XXXをオープン
3. RecurseDeleteKey()でサブキーを削除
0xf0000が指定されているのが、"AN", "BG", "SY"であることからFull Access (Allow or Deny)で
あることを強調するための慣習的なものだと妄想したいのですが・・・
# ドメイン環境で作用するとか、そんな都合のいい動作は無いですよね・・・
-
ちゃっぴ@ACL オタクです。
参照すべき document は下記ですね。
Service Security and Access Rights[追記]
あれ、資料が違っていた。上記は service ですね。ただ、原理は一緒だと思うんだけどなぁ~。
Service にしろ event log でも ACL は reistry に書き込まれるわけで、READ_CONTROL にしろ WRITE_DAC にしろそんなものは関係なく対象の registry key で ACL が許可されていれば対象の registry value は読み取れるわけです。Standard Access Rights は service の場合と同じくそれを制御する GetSecurityInfo のような API を通じての処理のみ生かされるのでしょう。
ただ、現状では event log の ACL が見当たらないんですよね。もしあるとしたら、advapi32.dll に実装されているんじゃないかと思いますが、無さそうな感じです。
そうなると event log では Standard Access Rights 自体が event log では現状 reserved 扱いなんじゃないかと。
推測ですが。[/追記]
-
こんにちは!
st.lain さん、ちゃっぴ さん、回答ありがとうございました。
フォーラム オペレータの鈴木裕子です
シャノン さん、フォーラムのご利用ありがとうございます。
st.lain さん、ちゃっぴ さんの回答が、有用な情報と思われたため、
私のほうで回答済みチェックをつけさせていただきました。
回答済みチェックが付くことにより、有用な情報を探している方が情報を見つけやすくなります。
有用な情報と思われる回答があった場合は、なるべく回答済みボタンを押してチェックを付けてくださいねシャノン さんはチェックを解除することもできますので、
もし不適切でしたら、修正をお願いします。
引き続き疑問や質問がありましたら、遠慮なく投稿してください。
それでは!