Skip to main content

File Access Rules

File Access rules enable Santa to control which processes can read and write files on macOS systems. This powerful feature allows administrators to monitor, log, and block file access attempts based on flexible policies.

Requirements

File Access rules require macOS 13 or later.

Overview​

File access authorization provides fine-grained control over file system access by allowing you to:

  • Log access events for audit and compliance
  • Block unauthorized access to sensitive files
  • Define policies based on both files and processes

File Access rules configure the policies that Santa uses to decide which files and processes to monitor and control access to.

Rule Types​

File Access supports four distinct rule types, categorized by orientation:

Data-Centric Rules​

These rules focus on protecting specific files or directories:

Paths with Allowed Processes​

Specifies which processes are allowed to access particular files or directories. Only the listed processes can access the protected paths, while all others are denied.

Use case: Protecting sensitive configuration files by allowing only specific system processes to access them.

Paths with Denied Processes​

Blocks designated processes from accessing specific files or directories. All processes except those listed are allowed to access the paths.

Use case: Preventing a particular application from accessing user documents or sensitive data.

Process-Centric Rules​

These rules focus on controlling what a process can access:

Processes with Allowed Paths​

Defines which paths a process is allowed to access. The process can only access the specified paths and is denied access to all others.

Use case: Sandboxing an untrusted application to only access specific directories.

Processes with Denied Paths​

Restricts a process from accessing specific paths. The process can access anything except the denied paths.

Use case: Preventing an application from accessing system directories or other users' home folders.

Rule Options​

Allow Read Access​

When checked, read access will be allowed.

Block Violations​

When unchecked, this rule will be in 'audit-only' mode, where violations will trigger events to be sent to Workshop but the access will not be blocked.

This is useful for testing policies before enforcement.

Enable Silent Mode​

When checked, this rule will not trigger notification dialogs from Santa, silently blocking the access without informing the user. This can be useful for preventing background processes from accessing files without interrupting the user but care should be taken to not use this in cases where the user is expecting the access to work.

Enable Silent TTY Mode​

When checked, this rule will not trigger notifications in the terminal, silently blocking access.

Paths​

File Access supports flexible path matching, using either literals (with optional wildcards) or prefixes.

Some rules to be aware of:

  • All paths are case-sensitive
  • Paths must reference resolved filesystem locations
  • Symbolic links are not supported - use the actual resolved path
  • Always use absolute paths, not relative paths

Path Literals​

Specify exact file or directory paths:

/etc/sudoers
/Users/admin/.ssh/id_rsa

You can also use standard wildcards for pattern matching:

/Users/*/Documents/*
/Applications/*.app

Standard libc glob(3) patterns are supported (excluding extended patterns like **):

/etc/*.conf
/var/log/app-[0-9]*.log

Path Prefixes​

Enable recursive directory monitoring:

/Users/admin/Documents/

Processes​

Processes can be matched using multiple identification methods, for flexibility when writing rules. You should use signing identifiers (Signing ID, Team ID, CDHash) rather than file paths, whenever possible. File paths can easily be changed, while code signing identifiers provide stronger security guarantees.

Binary Paths​

Match by full executable path:

/Applications/TextEdit.app/Contents/MacOS/TextEdit

Signing ID​

The code signing identifier assigned to the application, prefixed with the Apple developer team ID of the organization that signed it:

ABCDE12345:com.example.myapp

Use the special team ID platform for platform binaries that are part of the OS:

platform:com.apple.less

Team ID​

The Apple Developer Team ID:

ABCDE12345

CDHash​

The CDHash of the signed binary:

a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0

Leaf Certificate Hash​

The SHA-256 hash of the leaf certificate that was used to sign the binary:

1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef

Best Practices​

Start with Audit-Only Monitoring​

Before enforcing rules, enable audit-only mode to:

  • Understand normal access patterns
  • Identify legitimate processes that need access
  • Avoid accidentally blocking critical system operations

Maintain Specific Path Patterns​

Use the most specific path patterns possible:

  • Avoid overly broad wildcards like /*
  • Target specific directories or file types
  • Use prefix matching judiciously for large directory trees

Test Thoroughly​

Before deploying to production:

  • Test rules on non-critical systems first
  • Monitor logs for unexpected denials
  • Verify legitimate operations still work
  • Check for performance impact

For more detailed information about file access authorization configuration and examples, visit the Santa FAA Documentation.