Using default rules and access rules to protect registry keys from access with CBRegistry

When registry requests are sent to the registry subsystem, CBRegistry intercepts them and forwards these requests to user mode for verification. This process involves context switching between different operation modes, which can be relatively slow. Additionally, the extra operations needed during this handoff consume CPU resources, which can negatively impact overall system performance. Because of these factors, event-based protection of registry keys may not always be the best option.

Another limitation of event-based protection is its reliance on an application that must remain running. It's crucial to ensure this application is secure and that no DLLs are injected that could compromise its functionality.

To address these issues, CBRegistry supports two additional types of rules: Access Rules and Default Rules.

Access Rules

Access Rules can be set by the application and remain active while the application is running. They are designed to block all or specific types of access to a registry key without triggering an event. You can add an access rule using the same AddFilterRule method as event-based rules, which allows you to specify the mask and other conditions in a similar way. The following restrictions can be enforced using access rules:

• Read-only: A key may be read but not written to or deleted.
• Write-only: A key may be written to, but not read or deleted.
• No deletion: Deleting the key is prohibited.
• No renaming: Renaming is prohibited (keep in mind that a parent or grandparent key can still be renamed, which will change the "absolute path" of the key).
• No change of security attributes: Changes to security attributes are not allowed.
• No change of ownerr: Changes to the owner are not permitted.

The access flags can be combined within a single rule to protect a registry key from multiple operations.

A sample call to set up an access rule can look like this:

filter.AddFilterRule("\\HKEY_LOCAL_MACHINE\\SOFTWARE\\MyCoolSoftware\\Product\\*.*", Constants.ACCESS_READ_ONLY, Constants.REG_CE_NONE);

Default Rules

Default Rules are similar to Access Rules in terms of the protections they offer and the actions they can restrict. The main difference is that Default Rules remain in effect even when the controller application (the one that added the rules) is not running. These rules can be disabled by calling the SuspendDefaultRules method while the controller application is active. If suspended, the rules will be reactivated by the driver once the controller application is terminated or stopped.

A default rule is added using the AddDefaultRule method, like this:

filter.AddDefaultRule("\\HKEY_LOCAL_MACHINE\\SOFTWARE\\MyCoolSoftware\\Product\\*.*", Constants.ACCESS_READ_ONLY, "{your product GUID here}");

GUIDs are used to distinguish between the rules added by different applications.

Here's how Default Rules work behind the scenes:

1. An application adds one or more default rules.
2. When the application quits or is terminated, the driver activates these rules.
3. If the system is restarted, the driver loads at startup and immediately activates the previously set Default Rules.
4. When the application starts again, it can either suspend the Default Rules it set in step 1 or keep them active, depending on its logic.
5. The application can delete Default Rules at any time.

Getting started with CBRegistry

You can find an evaluation version of the SDK for your platform and programming language in the Download Center. After downloading and installing the SDK, you will receive a library, sample code, and comprehensive documentation on your system. The documentation includes a "Getting Started" section with programming instructions. Additionally, free technical support is available during the evaluation phase.