Introducing kernel-level app blacklisting with Google Santa
At Fleetsmith, it’s not enough for us to solve a problem for Apple admins — we’re passionate about solving it the right way. We want every feature we build to be performant, forward-looking, and secure by design.
That’s why we’re excited to announce the addition of Google Santa to the Fleetsmith Catalog. Santa solves a common problem for Mac admins: how to prevent employees from running harmful, unsupported, or otherwise problematic apps on their machines.
Yet what’s impressive about Santa is not just what it does, but how it does it. Santa offers low-level blocking based on signatures, coupled with employee-facing notifications that let admins communicate why things are being blocked and what users should do next. It’s an ideal mix of security, usability, and power that sets it apart from many other app blocking solutions available for Macs.
In this post we’ll tell you about Santa, how it works, why that matters for security, and how we integrated it seamlessly with Fleetsmith to make blacklisting through Santa as usable as possible.
Why Google Santa
To understand why Santa offers a better approach to blacklisting, it helps to look at how other solutions have tackled this challenge in the past.
The most basic approach, and the one taken by Apple’s own Parental Controls .mobileconfig, is to block applications by path. Under this scheme, you simply declare a certain path off limits for execution in the OS. For example, if you wanted to keep people from using FaceTime, you’d set up a block for its default install location /Applications/FaceTime.app.
Obviously, this is a brittle solution. If employees wanted to use FaceTime, they need only move the executable to some other location on their disk. This makes this kind of blacklisting too unreliable for most security applications — including parental controls if your child is particularly clever.
So engineers came up with a more robust way to block apps — monitor and kill. With this approach, the device has a service running that detects whenever a specified app is running and immediately kills the process running it. This is harder to evade — an employee would have to do a lot more than move a file to get around this kind of blacklisting.
Yet most of these monitoring processes are running in the same part of the Operating System that user accounts have access to — often referred to as “userland.” This means they’re sitting at the same layer as the things they’re trying to block, which essentially sets up a race between the user and the software doing the blocking. Sometimes, the user will win. This, frankly, isn’t good enough if you want to actually make a security guarantee. Can a security solution that only works sometimes even be called a solution?
Google, to its great credit, demands a higher bar for its security. So when they were evaluating options for blocking malicious apps on their own Mac fleet, they decided they needed something better — something that fulfilled the security guarantee of working every time.
They created a solution that blocks executions at the lowest level possible — at the kernel level. That means their blocker is running at such a fundamental level that there’s no way for a user to avoid it. For the things it can block (and there are some important limitations, which we’ll get into later), this is the most strict control possible, because there’s no way to execute a binary without going through Santa.
Google released this powerful implementation as an open source project in 2016, giving it the tongue-in-cheek name Santa because it keeps a list of which binaries are naughty or nice.🎅 📜
How it works in a little more depth
Google Santa consists of a kernel extension and an agent running in userland, the higher-level part of the OS that users can access. Although it’s technically two components, they’re designed to work together seamlessly, so employees are unlikely to notice this. Actually, they probably won’t notice Santa at all until it blocks something. It uses few resources and stays fairly invisible until it is needed.
Anytime a binary is executed on a system where Santa is installed, it is first hashed — a kind of “digital fingerprint” that uniquely identifies the application — and then logged by the kernel extension. The kernel extension will then check this “fingerprint” (hash) against a list specified by the IT admin to determine if the binary should be allowed to run.
If the binary passes this check, it runs as normal. If it doesn’t, it will not run. Whenever a binary is blocked the kernel extension communicates to the Santa agent, which displays a configurable message to the user. This gives IT a way to explain what happened and tell users what to do next, hopefully heading off frustrated calls to IT when a blacklisted app won’t launch.
Santa can be run in two different modes:
- In Monitor mode, Santa logs every execution and can optionally be configured to reject binaries based on path, hash, or even signing certificate, allowing you to blacklist every app by a given developer/company in a single stroke.
- In Lockdown mode, Santa will block all binaries except those specified by a whitelist. Santa will automatically whitelist itself and macOS components to prevent causing problems.
Here we see an example of a classic trade-off in the security world — security vs. usability. Monitor mode cannot guard against unknown threats, which limits how much protection it can offer. Yet it is the easier of the two to implement and is minimally disruptive to employees and IT. Lockdown mode, on the other hand, is extremely secure and offers broad protection against both known and unknown threats. Yet it is potentially disruptive in the extreme. Employees are always downloading new executables in the course of their work, and the majority of those files are going to be both useful and harmless. In Lockdown mode, Santa will block them all unless told not to. That gives the IT department a tough choice to make: work constantly to keep the whitelist up to date, or deal with a stream of angry emails from employees who can’t use the hot new app that was just released because it’s being blocked.
Thankfully, the folks at Google also devised a clever solution to this problem — they created a second open source sister project called Upvote that allows crowdsourcing the maintenance of the whitelist. Whenever a new app is blocked, Santa automatically uploads it to Upvote, where it appears as a candidate for whitelisting. Other employees can then vote on whether it’s good or bad. If enough employees vote “good,” the app is automatically whitelisted and becomes immediately unblocked on the entire fleet. Google open sourced this solution earlier this year.
Santa and Upvote create a great balance between usability and security, and have the added side benefit of making employees feel more invested in security, which helps to build strong security culture throughout an organization.
Since the majority of customer demand we’ve seen for Santa has revolved around various blacklisting use cases, we’re launching support for Monitor mode. If you’d like us to add support for Lockdown mode or using Santa with an Upvote server, we’d love to hear from you! Drop us a line at support@fleetsmithhq.com and tell us a bit about your use case. We’re committed to making security as easy and usable as possible, and we take customer feedback very seriously.
Google Santa & Fleetsmith
So what do you get by combining Santa with Fleetsmith? Plenty. We take care of:
- Deployment
- Configuration management
- Ongoing updates and patches
These are all things that you’d otherwise have to manage yourself, and this is no small feat. Although Santa is extremely powerful and customizable, it is difficult to implement at scale. To cite just one example, kernel extensions normally require active permission from an employee to install. This creates a two-fold problem for Mac admins: not only is it difficult to deploy, since admins need to either install it manually on every device or have their employees opt in themselves, it also gives those employees the ability to opt out. That’s dangerous, as it potentially leaves those devices unsecured with no easy way to fix it.
Yet Fleetsmith’s automatic kernel extension whitelisting makes deployment easy. You can add Santa to a Profile and have it install to your fully-managed devices just like any other app in the Fleetsmith Catalog, no user permission required.
Once Santa is installed, you can manage app blacklists for your whole fleet from within Fleetsmith. Blacklist by signature or block every app from a specific developer by blocking their signing certificate. You can also block by path if you need to, although this is a less secure option. The blacklist definitions you define within Fleetsmith are pushed out to your devices on a regular basis.
Just like any other app in the Fleetsmith Catalog, we will automatically keep Santa updated for you with no packaging or deployment tasks necessary on your end. From your employees’ standpoint, this is completely invisible. We whitelist the kernel extension and push everything in the background, a much better experience than trying to update it manually on your own.
What can I use Google Santa’s blacklisting for?
Santa is useful any time you need to prevent something you know is harmful from running on your devices with a high degree of certainty.
Imagine this scenario: say a major security vulnerability is discovered in an important piece of software that you use, such as the flaw exposed in Git earlier this year that lets attackers use it for remote code execution. A patch is quickly released, and you work to get the update applied, but you’re worried there might still be unpatched versions of the app floating around on your machines, creating a security risk.
You could launch an intensive find-an-eradicate program to try to track down and delete every last executable, but that would take time and effort. Or you could simply blacklist the older, insecure version of Git with Santa, setting an alert with information about the vulnerability and directing employees to upgrade to the patched version.
This would not only render the Git vulnerability harmless and drive patch adoption, it would also communicate to affected employees with no disruption to their workflow, and with almost no effort on IT’s part. It all takes just a few minutes in Fleetsmith.
As mentioned earlier, there are a few important limitations to keep in mind when using Google Santa with Fleetsmith:
- Santa running in Monitor mode isn’t a substitute for an anti-malware solution. It blocks known threats extremely well, but trying to keep up with the pace of malware on your own is an exercise in futility. However, the Fleetsmith Catalog offers a whole category of apps and settings related to Security & DevOps.
- Santa will not block users from running scripts.
- Santa will prevent a blacklisted binary from starting, but not things that are run from inside an allowed binary. So it won’t safeguard your system against clever injection attacks, or at least not by itself.
Santa gives Mac admins a powerful addition to their toolkit, and it does it in a way that is secure and lightweight. We’re excited to offer you a simple way to use it across your fleet.
We’re always looking for ways to improve our offerings, so let us know how you’re using it and what else would be helpful to you by reaching out at support@fleetsmithhq.com with any comments.
