File Access Policy Type

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.

How it works

  • Executable files are restricted at the point of execution, similar to the elevation policy.

  • Non-executable files (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.

Special Considerations

  • File Access policies won't apply if a target file is located in a "Protected Path". Learn more about protected paths.

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

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

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.

In this example, the cmd.exe application is executed successfully after administrative approval.

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.

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.

PreviousCommand Line Policy TypeNextManaging Requests

Last updated

Was this helpful?