santa

A binary authorization and monitoring system for macOS

4,484

297

4,484

View on GitHub

Top Related Projects

osquery

22,159

SQL powered operating system instrumentation, monitoring, and analytics.

wazuh

11,490

Wazuh - The Open Source Security Platform. Unified XDR and SIEM protection for endpoints and cloud workloads.

bless

2,736

Repository for BLESS, an SSH Certificate Authority that runs as a AWS Lambda function

Quick Overview

Santa is an open-source binary authorization system for macOS developed by Google. It monitors and controls the execution of binaries on a system, providing a layer of security by allowing or blocking processes based on configurable rules.

Pros

Enhances macOS security by controlling which binaries can run
Offers flexible rule-based configuration for fine-grained control
Provides both binary whitelisting and blacklisting capabilities
Integrates with existing macOS security features

Cons

Primarily focused on macOS, limiting its use on other platforms
May require significant setup and configuration for optimal use
Can potentially impact system performance due to constant monitoring
Might interfere with legitimate software if not configured correctly

Getting Started

To get started with Santa:

Clone the repository:

git clone https://github.com/google/santa.git

Build Santa using Xcode or the command line:

xcodebuild -project Santa.xcodeproj -target santa-driver -configuration Release

Install Santa:
```
sudo make install
```
Configure Santa by editing the configuration file:
```
sudo nano /var/db/santa/config.plist
```

Start the Santa service:

sudo launchctl load /Library/LaunchDaemons/com.google.santad.plist

For detailed configuration options and usage instructions, refer to the project's documentation on GitHub.

Competitor Comparisons

osquery

22,159

SQL powered operating system instrumentation, monitoring, and analytics.

Pros of osquery

Cross-platform support (Windows, macOS, Linux) vs. Santa's macOS-only focus
Broader scope for system information querying and monitoring
Larger community and more frequent updates

Cons of osquery

Higher resource usage and potential performance impact
Steeper learning curve due to its SQL-like query language
Less specialized in malware detection compared to Santa's focus

Code Comparison

osquery:

SELECT name, path, pid FROM processes WHERE on_disk = 0;

Santa:

- rule_name: "Block unsigned executables"
  rule_type: BINARY
  policy: BLOCKLIST
  custom_msg: "Unsigned executables are not allowed"
  conditions:
    - "certificate.signed" = false

Summary

Osquery offers a versatile, cross-platform solution for system monitoring and security, with a powerful SQL-like interface for querying system information. It provides broader functionality but may require more resources and expertise to use effectively.

Santa, on the other hand, is a specialized tool for macOS, focusing on binary authorization and malware detection. It's more lightweight and easier to configure for its specific use case but lacks the extensive querying capabilities and cross-platform support of osquery.

Choose osquery for comprehensive system monitoring across multiple platforms, or Santa for targeted macOS malware prevention and binary control.

wazuh

11,490

Wazuh - The Open Source Security Platform. Unified XDR and SIEM protection for endpoints and cloud workloads.

Pros of Wazuh

Comprehensive security platform with broader functionality (SIEM, XDR, SOAR)
Cross-platform support (Windows, Linux, macOS, etc.)
Active community and regular updates

Cons of Wazuh

More complex setup and configuration
Higher resource consumption due to extensive features
Steeper learning curve for new users

Code Comparison

Santa (Objective-C):

- (void)watchdogRun {
  while (YES) {
    @autoreleasepool {
      [self checkDaemonConnections];
      [NSThread sleepForTimeInterval:30];
    }
  }
}

Wazuh (C):

void wm_agent_upgrade_start() {
    mtinfo(WM_AGENT_UPGRADE_LOGTAG, "Module started.");

    while (1) {
        wm_agent_upgrade_check();
        sleep(wm_agent_upgrade_interval);
    }
}

Both repositories implement watchdog-like functionality, but Santa's code is in Objective-C (macOS-specific), while Wazuh uses C for broader platform compatibility. Santa's approach is more focused on daemon connections, whereas Wazuh's code snippet relates to agent upgrades, reflecting its more comprehensive feature set.

bless

2,736

Repository for BLESS, an SSH Certificate Authority that runs as a AWS Lambda function

Pros of Bless

Cross-platform support (Linux, macOS, Windows) vs Santa's macOS-only focus
More flexible certificate-based approach for signing and verifying binaries
Active development with recent updates and community contributions

Cons of Bless

Requires more setup and infrastructure compared to Santa's simpler approach
Less granular control over individual file execution policies
May have higher resource usage due to its broader feature set

Code Comparison

Santa (Objective-C):

- (void)validateBinaryWithURL:(NSURL *)url
                  certificateChain:(NSArray *)certificateChain
                           message:(SNTMessage *)message {
  // Validation logic
}

Bless (Python):

def validate_binary(binary_path, certificate_chain):
    # Validation logic
    return is_valid

Both projects implement binary validation, but Santa's implementation is more tightly integrated with macOS, while Bless offers a more platform-agnostic approach. Santa's code is in Objective-C, reflecting its macOS focus, while Bless uses Python for cross-platform compatibility.

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

Santa

[!NOTE] As of 2025, Santa is no longer maintained by Google. We encourage existing users to migrate to an actively maintained fork of Santa, such as https://github.com/northpolesec/santa.

Santa Icon

Santa is a binary and file access authorization system for macOS. It consists of a system extension that monitors for executions, a daemon that makes execution decisions based on the contents of a local database, a GUI agent that notifies the user in case of a block decision and a command-line utility for managing the system and synchronizing the database with a server.

It is named Santa because it keeps track of binaries that are naughty or nice.

Docs

The Santa docs are stored in the Docs directory and are published at https://santa.dev.

The docs include deployment options, details on how parts of Santa work and instructions for developing Santa itself.

Get Help

If you have questions or otherwise need help getting started, the santa-dev group is a great place.

If you believe you have a bug, feel free to report an issue and we'll respond as soon as we can.

If you believe you've found a vulnerability, please read the security policy for disclosure reporting.

Features

Multiple modes: In the default MONITOR mode, all binaries except those marked as blocked will be allowed to run, whilst being logged and recorded in the events database. In LOCKDOWN mode, only listed binaries are allowed to run.
Event logging: When the system extension is loaded, all binary launches are logged. When in either mode, all unknown or denied binaries are stored in the database to enable later aggregation.
Certificate-based rules, with override levels: Instead of relying on a binary's hash (or 'fingerprint'), executables can be allowed/blocked by their signing certificate. You can therefore allow/block all binaries by a given publisher that were signed with that cert across version updates. A binary can only be allowed by its certificate if its signature validates correctly but a rule for a binary's fingerprint will override a decision for a certificate; i.e. you can allowlist a certificate while blocking a binary signed with that certificate, or vice-versa.
Path-based rules (via NSRegularExpression/ICU): This allows a similar feature to that found in Managed Client (the precursor to configuration profiles, which used the same implementation mechanism), Application Launch Restrictions via the mcxalr binary. This implementation carries the added benefit of being configurable via regex, and not relying on LaunchServices. As detailed in the wiki, when evaluating rules this holds the lowest precedence.
Failsafe cert rules: You cannot put in a deny rule that would block the certificate used to sign launchd, a.k.a. pid 1, and therefore all components used in macOS. The binaries in every OS update (and in some cases entire new versions) are therefore automatically allowed. This does not affect binaries from Apple's App Store, which use various certs that change regularly for common apps. Likewise, you cannot block Santa itself, and Santa uses a distinct separate cert than other Google apps.
Userland components validate each other: each of the userland components (the daemon, the GUI agent and the command-line utility) communicate with each other using XPC and check that their signing certificates are identical before any communication is accepted.
Caching: allowed binaries are cached so the processing required to make a request is only done if the binary isn't already cached.

Intentions and Expectations

No single system or process will stop all attacks, or provide 100% security. Santa is written with the intention of helping protect users from themselves. People often download malware and trust it, giving the malware credentials, or allowing unknown software to exfiltrate more data about your system. As a centrally managed component, Santa can help stop the spread of malware among a large fleet of machines. Independently, Santa can aid in analyzing what is running on your computer.

Santa is part of a defense-in-depth strategy, and you should continue to protect hosts in whatever other ways you see fit.

Security and Performance-Related Features

Known Issues

Santa only blocks execution (execve and variants), it doesn't protect against dynamic libraries loaded with dlopen, libraries on disk that have been replaced, or libraries loaded using DYLD_INSERT_LIBRARIES.
Scripts: Santa is currently written to ignore any execution that isn't a binary. This is because after weighing the administration cost vs the benefit, we found it wasn't worthwhile. Additionally, a number of applications make use of temporary generated scripts, which we can't possibly allowlist and not doing so would cause problems. We're happy to revisit this (or at least make it an option) if it would be useful to others.

Sync Servers

The santactl command-line client includes a flag to synchronize with a management server, which uploads events that have occurred on the machine and downloads new rules. There are several open-source servers you can sync with:
- Moroz - A simple golang server that serves hardcoded rules from simple configuration files.
- Rudolph - An AWS-based serverless sync service primarily built on API GW, DynamoDB, and Lambda components to reduce operational burden. Rudolph is designed to be fast, easy-to-use, and cost-efficient.
- Zentral - A centralized service that pulls data from multiple sources and deploy configurations to multiple services.
- Zercurity - A dockerized service for managing and monitoring applications across a large fleet utilizing Santa + Osquery.
Alternatively, santactl can configure rules locally (without a sync server).

Screenshots

A tool like Santa doesn't really lend itself to screenshots, so here's a video instead.

Santa Block Video

Contributing

Patches to this project are very much welcome. Please see the CONTRIBUTING doc.

Disclaimer

This is not an official Google product.

Top Related Projects

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot