Access and Default Rules in CBFS Filter

CBFS Filter supports three types of rules for processing filesystem requests:

1. Standard Filter Rules: These rules fire corresponding events in the user mode, which involves context switches between different operation modes and can be relatively slow. Additionally, the supplementary operations required during this passing consume CPU time, negatively affecting overall system performance. For these reasons, event-based protection of files and directories using standard filter rules may not always be optimal. These rules are applicable only when the application is running.
2. Access Rules: These rules do not fire events in the user mode and instead are processed by the component's system driver. These rules are applicable only when the application is running.
3. Default Rules: These rules do not fire events and do not require an application to be running. These rules are managed and processed by the component's system drive.

When filesystem requests reach the filter stack, CBFilter intercepts them to check for rule matches. The following sections discuss the use of Access Rules and Default Rules in more detail for cases in which Standard Rules are not suitable.

Access Rules

Access Rules can be set by the application and remain active while the application is running. They are used to block all or specific forms of access to a file or directory without firing an event. An access rule is added using the same AddFilterRule method as event-based rules, allowing the mask and other conditions for the rule to be specified in the same manner. The following restrictions can be set by using access rules:

• Read-only - A file may be read but not written or deleted.
• Write-only - A file may be written, but not read or deleted.
• No deletion - Deletion is prohibited.
• No renaming - Renaming is prohibited (remember that a parent or grandparent directory can still be renamed, so the absolute path of the file will be changed).
• No change of security attributes - Changing security attributes is prohibited.
• No change of owner - Changing ownership is prohibited.
• No remote access - The file can be accessed by a local process, but if a request comes from a remote system across the network, such request will be denied.
• No execution - A file cannot be used to create a process.

The access flags can be combined within one rule to protect a file or directory from multiple operations.

A sample call to set up an access rule can look like this: filter.AddFilterRule("C:\\protected\\*.*", Constants.ACCESS_WRITE_ONLY, Constants.FS_CE_NONE, Constants.FS_NE_NONE);

Default Rules

Default Rules are similar to Access Rules in terms of what they can protect and which actions can be restricted. The primary difference is that Default Rules are applied even when the controller application (the one that added the rules) is not running. These rules can be disabled with a call to the SuspendDefaultRules method while the controller application is active. If suspended, the rules will be reactivated by the driver after the controller application is terminated or stopped.

A default rule is added using the AddDefaultRule method, like this: filter.AddDefaultRule("C:\\protected\\*.*", Constants.ACCESS_WRITE_ONLY, "{your product GUID here}"); Globally unique identifiers (GUIDs) are used to distinguish among the rules added by different applications.

Behind the scenes, Default Rules function as follows:

1. An application adds one or more default rules.
2. When the application quits or is terminated, the driver activates the rules.
3. If the system is restarted, the driver loads at the next startup and immediately activates the previously set Default Rules.
4. If the application is started 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.

Because Default Rules provide protection for files while the application is not running (but the driver is), it is crucial to safeguard these rules from deletion by unauthorized users. One measure to achieve this is by defining allowed controllers for the driver. This is done by specifying which application or applications may communicate with the driver during installation. Once this restriction is set, the driver will reject requests from other applications, preventing them from modifying or deleting Default Rules. Allowed controllers are specified through the corresponding parameter of the Install method.

Getting Started with CBFilter

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.