# File Access Policy Type

### Overview File Access policies control access to specific files, implementing fine-grained access control for sensitive data, configuration files and system files. The file access policy restricts access to **executable files** and **non-executable** files. File Access policies may operate within broader default-deny enforcement models, requiring explicit authorization or policy approval before sensitive files can be accessed or executed. #### How it works * Executable files are restricted at the point of execution, similar to the elevation policy. * Non-executable file enforcement, which leverages the native operating system's ACLs, (e.g. text file, database file, configuration file, etc) will deny `READ/WRITE/DELETE` of the file without adhering to the enforcement (MFA, justification, approval). * The File Access policy will apply to **any user** of the system, not just a standard user. * File Access requests can be initiated from both the Keeper Client and command-line interface, ensuring consistent enforcement and workflow parity across user interaction models. #### Special Considerations * If you have file access and elevation policy on the same executable, the file access policy won't apply and Keeper will **only** apply the elevation policy. * File Access policy evaluation may incorporate contextual risk signals as part of enforcement decisions, supporting organizations that align file governance with broader risk management strategies. * Keeper supports [Path Variables](#path-variables) for assigning policy to a common folder or path on the endpoint. * Keeper modifies the ACL of a target file explicitly to a user that the policy has been applied to. Keeper will explicitly add the user, then apply the ACL. When a user requests access to a file, and the file access is approved, Keeper modifies the ACL for that user read/write permission to "allow". On Linux systems, if the user is a member of a group which already has "allow" permissions, the user will be able to access the file based on their group membership, regardless of what Keeper enforces. *** {% stepper %} {% step %} ### Create an Application Collection Before creating the policy, the target files must be organized into an **Application Collection**. Navigate to **Collections → Applications** and click on the **New Collection** button. This will bring up the **New Collection** modal form. Select **Applications** from the Type select box, give your collection a recognizable descriptive name, and click the **Next** button.

You sholud now see the **Add Item to Collection** modal form. You can either Type object to add and select from the objects that match the string that you type, or you can check the **Manually define resource** checkbox and manually define your resources. Add each target file as a custom resource, using [Path Variables](https://docs.keeper.io/en/keeperpam/endpoint-privilege-manager/policies/policy-types/broken-reference) where applicable to avoid hardcoded paths (e.g. `{system32}\powershell.exe`). Once you have selected or entered the resource that you want to add to your collection, click the **Add** button and repeat the process until youhave all of the resources that you would like to see in your application collection added.

> **Tip:** Give the collection a descriptive name that reflects its purpose — for example, "Restricted System Tools" or "Protected Config Files" — to make it easy to identify when assigning it to a policy.

{% endstep %} {% step %} ### Open the Policy Form From the Keeper Admin Console, navigate to **Endpoint Privilege Manager → Policies** and click **Create Policy**. This will open the Create Policy modal form.

{% endstep %} {% step %} ### Configure the Policy Fill in the policy details: * **Policy Name** — Enter a descriptive name (e.g. `File Access – Restricted System Tools`, `File Access – Protected Config Files`) * **Policy Type** — Select `File Access` * **Status** — Select `Enforce` to apply the policy actively

> **Tip:** Consider starting with **Monitor** status to observe how frequently the policy would match before enabling enforcement. > {% endstep %} {% step %} ### Select a Control Click **Add Control** and select the control to apply when a user triggers an elevation event: * **Require Approval** — Elevation is blocked until an assigned approver grants the request * **Require MFA** — User must verify their identity with a TOTP code before elevation proceeds * **Require Justification** — User must provide a written reason before elevation proceeds

Multiple controls can be added to a single policy. When controls are stacked, all must be satisfied before the elevation is permitted. {% endstep %} {% step %} ### Set Policy Filters Below the **Add Control** button, define the scope of the policy by applying filters: * **User Groups** — Select the user group collections to target, or choose **Select All** to apply to all users * **Machines** — Select the machine collections to target, or choose **Select All** to apply to all enrolled endpoints * **Applications** — Select the Application Collection created in Step 1 * **Date & Time Window** — Optionally restrict the policy to specific dates, days of the week, or time ranges

> Selecting **Select All** on any filter dimension creates a wildcard that automatically includes new users, machines, or applications added to those collections in the future. > {% endstep %} {% step %} ### Save and Deploy Once the form has been sufficiently filled in per the previous steps, the **Save** button will be changed from an inactive to an active state. Click on the **Save** button.

The policy will be pushed to all in-scope endpoints within approximately **30 minutes**. Users on affected endpoints can also trigger an immediate sync via the **Refresh Policies** option in the Keeper agent. When the policy is applied, affected users will receive an on-screen notification informing them that they have been removed from the local Administrators group. {% endstep %} {% endstepper %} ### Example 1: File Access Policy on Executables As an example, let's say you want to restrict users from executing specific applications that are typically only used by IT team members. This may prevent threats such as "living off the land" where malware takes advantage of common tools. A list of tools that fall into this category might look like this: ``` {system32}\cmd.exe {system32}\certutil.exe {system32}\cscript.exe {system32}\PATHPING.EXE {system32}\PING.EXE {system32}\NDKPing.exe {system32}\RpcPing.exe {system32}\WMIC.exe {system32}\WindowsPowerShell\v1.0\powershell.exe {system32}\WindowsPowerShell\v1.0\powershell_ise.exe ``` {% stepper %} {% step %} #### Create Collection In the **Collections** > **Applications**, create a new Collection. For example, this one is called "Restricted Files on Windows". Add the files to the collection as custom resources. Note: the `{system32}` variable is defined in our list of [Path Variables](#path-variables).

{% endstep %} {% step %} #### Create File Access Policy From the Policies screen, create a "File Access" policy that has specific controls. The application collection assigned is the "Restricted Files on Windows" collection.

{% endstep %} {% step %} #### User Experience When the user (in this case, the "standard" user) attempts to execute any of the applications listed, they will receive a prompt from Keeper that requests justification and approval.

After the request is approved, the Keeper Client application will display the request. The user can then launch it directly from the user interface.

{% endstep %} {% endstepper %} *** ### Example 2: Protection of a System File In this example, we will require approval to access a protected file called "netlogon.inf" on all Windows machines. {% stepper %} {% step %} #### Create Collection Create a "Protected Files" collection which will hold the protected file resources.

Create a new Collection of Protected Files

{% endstep %} {% step %} #### Add Item to Collection Click on "Manually define resource" and add the `netlogon.inf` file to the collection.

{% endstep %} {% step %} #### Create a Policy From the Policy tab, click on Create Policy and select: **Policy Type**: File Access **Status**: Enforce **Add Control**: Select MFA, Justification or Approval **User Groups**: Select the users or groups affected, or All Users and Groups **Machines**: Select which machines to apply the policy, or All Machines **Applications**: Select the "Protected Files" collection as defined above.

To require approval by an admin for accessing the file resource, select "Requires Approval" and then select the approver(s).

After saving the policy, it will apply to all affected machines within a few minutes. {% endstep %} {% endstepper %} *** ### Path Variables When defining a File Access policy, variables can be used to simplify the policy creation process, and to avoid hard-coded paths. #### Built-in Path Variables **Windows Variables** * `{windows}` → `C:\Windows` (Windows directory) * `{system32}` → `C:\Windows\System32` (System32 directory) * `{syswow64}` → `C:\Windows\SysWOW64` (32-bit system directory) * `{systemdrive}` → `C:\` (System drive root) * `{userprofile}` → `C:\Users\username` (User profile directory) * `{programdata}` → `C:\ProgramData` (Program data directory) * `{programfiles}` → `C:\Program Files` (Program Files directory) * `{programfilesx86}` → `C:\Program Files (x86)` (32-bit Program Files) * `{temp}` → `C:\Users\username\AppData\Local\Temp` (Temp directory) * `{appdata}` → `C:\Users\username\AppData\Roaming` (Application data) * `{localappdata}` → `C:\Users\username\AppData\Local` (Local application data) **macOS Variables** * `{system}` → `/System` (System directory) * `{library}` → `/Library` (Library directory) * `{home}` → `/Users/username` (User home directory) * `{applications}` → `/Applications` (Applications directory) * `{volumes}` → `/Volumes` (Volumes directory) * `{temp}` → `/tmp` (Temporary directory) **Linux Variables** * `{usr}` → `/usr` (User directory) * `{home}` → `/home/username` (User home directory) * `{temp}` → `/tmp` (Temporary directory) * `{root}` → `/` (Root directory) **Cross-Platform Variables** * `{userdocuments}` → User Documents directory * `{userdesktop}` → User Desktop directory *** ### Protected Paths Keeper Endpoint Privilege Manager maintains a comprehensive list of protected paths across all supported platforms. These paths represent critical system directories and files that should not be modified by standard users and are excluded from ACL enforcement to maintain system integrity. ### Protection Categories #### 1. Protected Directories System directories that are automatically protected from ACL modifications. #### 2. High-Risk Paths Critical system files that should never be modified and are blocked from storage operations. #### 3. Critical System Paths Virtual filesystems and problematic paths that are avoided during inventory scanning. ### Platform-Specific Protected Paths #### Windows Protected Directories The following directories are protected on Windows systems: ``` C:\Windows\System32 C:\Windows\SysWOW64 C:\Windows\WinSxS C:\Program Files\Windows NT C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup ``` **Variable-Based Protected Paths** (resolved at runtime): ``` {system32} {systemroot}\SysWOW64 {systemroot}\WinSxS {programfiles}\Windows Defender {systemroot}\System32\config {systemroot}\System32\drivers ``` #### Windows High-Risk Paths Critical system files that should never be modified: ``` C:\Windows\System32\config C:\Windows\System32\drivers ``` #### Linux Protected Directories Critical system directories and files on Linux systems: ``` /bin /sbin /usr/bin /usr/sbin /boot /dev /proc /sys /etc/passwd /etc/shadow /etc/sudoers ``` #### Linux High-Risk Paths Critical system files on Linux: ``` /etc/passwd /etc/shadow /bin/sh /sbin/init ``` #### macOS Protected Directories System directories and critical files on macOS: ``` /System /bin /sbin /usr/bin /usr/sbin /private/etc /Library/Security /Applications/Utilities ``` #### macOS High-Risk Paths Critical system paths on macOS: ``` /System/Library/CoreServices /private/etc (and /etc) ``` #### Generic Unix Protected Directories Fallback protected directories for unknown Unix variants: ``` /bin /sbin /usr/bin /usr/sbin /etc /dev /proc /sys ``` *** ### Mac and Linux Policy Enforcement On macOS and Linux devices, the File Access policy currently requires the use of the Keeper Client application user interface. To request file access, the user has to request it via the system tray "**Request Access**" feature.