File Access

File access policy management

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 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.

---

1

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 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.

2

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.

3

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.

4

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.

5

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.

6

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.

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

1

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.

2

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.

3

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.

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.

1

Create Collection

Create a "Protected Files" collection which will hold the protected file resources.

Create a new Collection of Protected Files

2

Add Item to Collection

Click on "Manually define resource" and add the netlogon.inf file to the collection.

Add Item to Collection

3

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.

Create Policy

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

Require Approval on File Access

After saving the policy, it will apply to all affected machines within a few minutes.

When defining a File Access policy, variables can be used to simplify the policy creation process, and to avoid hard-coded paths.

Path Variables

Path variables are placeholders like {userprofile} or {system32} that resolve to real paths on each machine. They let you write one policy or job that works on every supported OS and install location.

• Format: {variableName} — curly braces, no $ prefix.

• Case: Resolved case-insensitively on Windows; case-sensitive on Linux and macOS.

• When resolved: At evaluation time (when the policy or job runs), not when the file is saved.

Common Path Variables (all platforms)

Variable

Windows example

Linux example

macOS example

Description

{rootdir}	C:\	/	/	Drive or filesystem root
{documents}	C:\Users\<user>\Documents	/home/<user>/Documents	/Users/<user>/Documents	User documents folder
{userdocuments}	Same as {documents}	Same as {documents}	Same as {documents}	Alias for documents
{userdesktop}	C:\Users\<user>\Desktop	/home/<user>/Desktop	/Users/<user>/Desktop	User desktop
{hasdesktop}	"true" / "false"	"true" / "false"	"true" / "false"	Whether a desktop environment is present

Windows-Specific Path Variables

Variable

Typical value

Description

{systemroot}	C:\Windows	Windows directory
{windows}	C:\Windows	Alias for systemroot
{systemdrive}	C:	System drive (no trailing backslash)
{system32}	C:\Windows\System32	System32 directory
{syswow64}	C:\Windows\SysWOW64	32-bit system on 64-bit Windows
{programfiles}	C:\Program Files	Program Files
{programfilesx86}	C:\Program Files (x86)	Program Files (x86)
{userprofile}	C:\Users\<user>	User profile directory
{appdata}	C:\Users\<user>\AppData\Roaming	Roaming AppData
{localappdata}	C:\Users\<user>\AppData\Local	Local AppData
{programdata}	C:\ProgramData	ProgramData
{temp}	C:\Users\<user>\AppData\Local\Temp	User temp directory

macOS Specific Path Variables

Variable	Example	Description
{system}	/System	System root
{library}	/Library	Library
{applications}	/Applications	Applications folder
{volumes}	/Volumes	Volumes mount point
{downloads}	/Users/<user>/Downloads	User downloads
{launchdaemons}	/Library/LaunchDaemons	System launch daemons
{launchagents}	/Library/LaunchAgents	Launch agents

Linux and macOS Shared Path Variables

Variable

Linux example

macOS example

Description

{bin}	/bin	/bin	Binaries
{etc}	/etc	/etc	Configuration
{tmp}	/tmp	/tmp	Temp
{usr}	/usr	/usr	User programs
{var}	/var	/var	Variable data
{home}	/home/<user>	/Users/<user>	User home

Application-Specific Path Variables

These resolve relative to the Keeper Privilege Manager install:

Variable	Description	Example (Windows)
{approot}	Application root directory	C:\Program Files\KeeperPrivilegeManager
{pluginroot}	Plugins directory	C:\Program Files\KeeperPrivilegeManager\Plugins
{jobroot}	Jobs directory	C:\Program Files\KeeperPrivilegeManager\Jobs

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

Linux Default Protected Paths

Executables in these paths are excluded from wildcard File Access DENY policies. Protection applies recursively to all subdirectories. Explicit path policies are always evaluated regardless of protection status.

Path	Description
/bin	Essential system binaries
/sbin	System administration binaries
/usr/bin	User-facing system utilities
/usr/sbin	System administration utilities
/usr/lib	System shared libraries
/usr/libexec	System daemon executables
/lib	Essential shared libraries
/lib64	64-bit essential shared libraries
/etc	System configuration files
/etc/passwd	User account database
/etc/shadow	Encrypted user password store
/etc/sudoers	sudo privilege configuration
/boot	Boot loader and kernel files
/dev	Device files
/proc	Kernel and process information (virtual filesystem)
/sys	Hardware and driver information (virtual filesystem)
/opt/keeper	Keeper Privilege Manager installation directory

Linux High-Risk Paths

The following paths contain critical system files and should never be targeted by File Access policies. Modification to files in these locations can corrupt authentication, disable system initialization, or render the system unbootable.

Path	Description	Risk
/etc/passwd	User account database	Corruption breaks all user authentication system-wide
/etc/shadow	Encrypted user password store	Corruption prevents password-based login for all users
/bin/sh	Default system shell	Corruption breaks scripts, system init, and recovery tools that depend on sh
/sbin/init	System initialization process (PID 1)	Corruption prevents the OS from booting

Learn more about how Policy: Wildcards behave in application vs. folder filters and what to avoid.

Generic Unix Default Protected Paths

These paths serve as the fallback protected directory set for Unix-based environments where a platform-specific list is not defined. Explicit path policies are always evaluated regardless of protection status.

Path	Description
/bin	Essential system binaries
/sbin	System administration binaries
/usr/bin	User-facing system utilities
/usr/sbin	System administration utilities
/etc	System configuration files
/dev	Device files
/proc	Kernel and process information (virtual filesystem)
/sys	Hardware and driver information (virtual filesystem)

macOS Default Protected Paths

Wildcard File Access DENY policies are bypassed for executables in these paths. Explicit path policies are always evaluated regardless of protection status.

Path	Description
/System	macOS system root and all subdirectories
/bin	Essential system binaries
/sbin	System administration binaries
/usr/bin	User-facing system utilities
/usr/sbin	System administration utilities
/private/etc	System configuration files
/Library/Security	Security framework
/Applications/Utilities	Built-in utility applications
/Applications	All applications in the main Applications directory
/System/Applications	Built-in macOS applications

macOS High-Risk Paths

The following paths contain critical system files and should never be targeted by File Access policies. Modification to files in these locations can corrupt core OS services, break authentication, or render the system unbootable.

Path	Description	Risk
/System/Library/CoreServices	Core macOS system services including the Finder, WindowServer, and boot components	Corruption breaks system startup, the GUI environment, or both
/private/etc	System configuration files (also accessible as /etc)	Corruption to files such as passwd, sudoers, or hosts breaks authentication, privilege resolution, and network behavior

/Applications and /System/Applications are protected by design. For the full rationale and guidance on where to scope wildcard vs. explicit path policies, see macOS Protected Path Design Intent for greater detail.

Windows Default Protected Paths

Executables in these paths are excluded from wildcard File Access DENY policies. Protection is recursive — all subdirectories are included. Explicit path policies are always evaluated regardless of protection status.

The list can be extended via a ProtectedPaths policy or the UserProtectedDirectories.json / PolicyProtectedDirectories.json files under the PathResolution storage folder.

Variable	Resolves To (Typical)	Description
{systemroot}	C:\Windows	Windows directory root and all subdirectories
{system32}	C:\Windows\System32	Core system binaries
{systemroot}\SysWOW64	C:\Windows\SysWOW64	32-bit system binaries on 64-bit Windows
{systemroot}\WinSxS	C:\Windows\WinSxS	Side-by-side component assemblies
{systemroot}\servicing	C:\Windows\servicing	Windows Update and Servicing Stack
{systemroot}\Microsoft.NET	C:\Windows\Microsoft.NET	.NET Framework runtime files
{systemroot}\assembly	C:\Windows\assembly	Global Assembly Cache (GAC)
{systemroot}\Boot	C:\Windows\Boot	Boot manager files
{systemroot}\recovery	C:\Windows\recovery	Windows Recovery Environment
{systemroot}\System32\config	C:\Windows\System32\config	Registry hive files
{systemroot}\System32\drivers	C:\Windows\System32\drivers	Kernel-mode device drivers
{programfiles}	C:\Program Files	Installed 64-bit applications
{programfilesx86}	C:\Program Files (x86)	Installed 32-bit applications on 64-bit Windows
{programfiles}\Windows Defender	C:\Program Files\Windows Defender	Windows Defender antivirus binaries
{programfiles}\Windows NT	C:\Program Files\Windows NT	Core Windows NT components
N/A	C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup	System startup programs

Windows High-Risk Paths

The following paths contain critical system files and should never be targeted by File Access policies. Modification to files in these locations can corrupt the registry, destabilize drivers, or render the system unbootable.

Path	Description	Risk
C:\Windows\System32\config	Registry hive files (SYSTEM, SAM, SECURITY, SOFTWARE)	Registry corruption; system unbootable
C:\Windows\System32\drivers	Kernel-mode device drivers (.sys files)	Driver failure; Blue Screen of Death (BSOD)

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.