[Vrtule]

Hello,

I am developing a registry filter driver that uses Registry Callback (**CmRegisterCallback(Ex)**) to achieve its goal. I am encountering some problems when implementing RegNtPreCreateKeyEx/RegNtPreOpenKeyEx and related post-notifications.

My question is: how to determine access rights that are really granted to the caller when a registry key is created/opened? I know the access rights desired by the caller, however, they can quite differ from the rights actually granted.

* The mask can contain generic rights which is not really a problem since I can manually (and easily) translate them.
* The MAXIMUM_ALLOWED "access rights" seems to be a bigger issue. In theory, I can obtain a security descriptor of the registry key in question during the post-notification callback. Then, I can try the **SeAccessCheck**.
* The caller can have **SeBackupPrivilege** and/or **SeRestorePrivilege** enabled in her access token. When the key is created/opened with **REG_OPTION_BACKUP_RESTORE** flag set, GENERIC_READ and/or GENERIC_WRITE access rights are automatically granted to the caller.

I thought that the **GrantedAccess** member of the **REG_CREATE_KEY_INFORMATION** can help me to avoid to manually solve all three cases above. However, it seems that the member is not used in general, and the documentation suggests that it can be used by drivers taht modifies the registry operation in some way.

So, is there a way how to determine the granted access rights without doing that manual work?

Thanks in advance
Vrtule

[FileSystem_Driver]

hi , You can use the following function to obtain the rights to use an object , This object could be a registry key ,

Code: Select all

NTSTATUS ZwQuerySecurityObject(
  _In_   HANDLE Handle,
  _In_   SECURITY_INFORMATION SecurityInformation,
  _Out_  PSECURITY_DESCRIPTOR SecurityDescriptor,
  _In_   ULONG Length,
  _Out_  PULONG LengthNeeded
);

http://msdn.microsoft.com/en-us/library ... 85%29.aspx

[Vrtule]

Hello,

I decided to try to filter the create/open requests in the post-notification. The GrantedAccess fields seems to work correctly there and it do not contain things like MAXIMUM_ALLOWED "access right". When I decide to block the operation, I just fail the post-notification. Blocking create operation means deleting the key that is already created, which is not nice, however, I am failingto find better solution.

Filtering create and open requests inside post-notification has also the advantage that the following types of race conditions are not possible:
1) an application attempts to open a registry key with REG_OPTION_BACKUP_RESTORE. The application has SeBackupPrivilege enabled,
2) my pre-notification is configured to block only open operations that request write access, so it does not block this request,
3) the application enables SeRestorePrivilege,
4) the key is opened with write access.