For the next stop in our journey, we’ll review that jolly ol’ soul, Santa. It’s a system for either monitoring what apps are launched and blacklisting the ones you decide are bad, or locking down a macOS computer to only run the ones you’ve whitelisted. Despite what The Register seems to believe, it’s been ‘in development’ (which Google calls… production use at scale,) in the open on GitHub for nearly two years. Like Munki and osquery, we should think of 🎅 primarily as a tool that does the majority of the heavy-lifting client-side. This is a common ‘agent’ model, as real-time decision-making requires it, and the most intensive work is best suited to the often idle distributed CPU’s on workstations. As it was originally designed for Google’s specific use case, there is some overlap with similar functions built into macOS or other security tools, but they’ve implemented things (e.g. File Integrity Monitoring) in a way that contrasts favorably with other tools.
Google’s server implementation, while not yet open-sourced, involves letting end users vote on being allowed to launch apps that have not yet been encountered and explicitly whitelisted by IT. How is having to whitelist apps before use not death by a thousand cuts for their customers? Apple’s Gatekeeper push, quarantining downloads and helpfully offering users the option of dragging apps from ‘unknown’ (meaning not in the Developer ID program curated by Apple) developers to the trash has put a lot of pressure on them to get their apps signed. When an app can prove a cert-based chain of trust that Apple has established (and can revoke at any time), and the majority of your customers use apps from a handful of common developers, you can whitelist those certs instead of the actual fingerprint of the app bundle itself, and updates or other apps by that developer would be similarly covered. This makes it a scalable and low-ish maintenance system.
When it comes to stopping the launch of apps your org wants to restrict, users of Apple’s old Workgroup Manager or Profile Manager have been able to accomplish something similar with an operating-system-level feature called mcxalr, Application Launch Restriction. LaunchServices, which ties a file type with applications that can register to handle/open it, is the implementation behind that. At different times in the life of macOS, LaunchServices has been observed to be less than ideal as a foundation, and as it is running up in userland (like some management tools naïvely watch application launches from only certain paths,) it certainly is not all that efficient. The plus of that technique was you could manage it by filesystem path – which 🎅 just happens to have as well, through WhitelistRegex/BlacklistRegex configuration keys. So we end up with three ‘tiers’ of priority that 🎅 will evaluate, in order,
- (highest priority) ‘fingerprint’ or hash/sha of the specific binary/application version itself
- the leaf (most specific to the developer) SHA256 identifier of the cert used to sign the app
- (lowest priority) a filesystem path
A basic 🎅 install (e.g. by running
autopkg install Santa) leaves you in ‘MONITOR’ mode, during which only explicitly blacklisted apps will be blocked. Sierra’s AppTranslocation system, to move apps (e.g. launched from a DMG they just downloaded) to an ad-hoc sorta-sandbox in a temporary path away from user data or supporting files throws a wrench in path-based rules, so the devs recommend not relying on it as your primary way of protecting against app launches. It still is beneficial during evaluation to take a half-step towards a more controlled environment by using a BlacklistRegex for home folders with the following command:
sudo defaults write /var/db/santa/config.plist BlacklistRegex "'^(?:/Users)/.*'"
For those worried about accidentally blocking critical macOS components from running, 🎅 has ‘failsafe’ whitelisting for its own certs and launchd. Every OS component and each update therefore gets whitelisted ‘for free’, as well. And for the Google-wary, they use a separate signing cert than the one the Chrome browser/Google Earth app/etc. would have. Similarly, apps from the App Store use a range of different certs than the OS. (Case in point: unlike the rest of Office 2016, Microsoft Remote Desktop and OneDrive from the App Store have different cert SHA256’s, with the authority listed as “Apple Mac OS Application Signing”.) You can still blackhole a specific release that has an issue, even if you’ve whitelisted the cert, by making a rule for that one binaries hash, due to the higher priority.
Since 🎅 relies on a kernel extension as one of its moving parts, some security personnel are wary of it – other commercial products have a reputation of poor design, performance, and maintainability. These folks aren’t privy to the ahem ’emphatic feedback’ the MacOps team at Google gets from their customers. That teams rounding errors are bigger than most people’s fleet, and they’ve logged easily millions of binaries over the time they were in MONITOR mode. 🎅 was developed using KPI’s, kauth interfaces for kernel development that, to date, have required very little modification with OS updates. It also cross-validates itself between components at startup, and locks direct sqlite access to the rules database while the daemon is running. In-kernel caching is used to increase performance, and moving parts are constantly re-evaluated to ensure things run in parallel wherever possible. You can check its system impact at any time with
Watchdog CPU Events | 0 (Peak: 7.16%)
Watchdog RAM Events | 0 (Peak: 20.20MB)
One of the items stated in the 🎅 readme under known issues is that the threat model used when designing it was to leave out restrictions on scripts. However, anything that uses an interpreter like Python or Ruby to launch are still logged, along with any arguments they may be called with. Some daemonized processes, especially those that run scripts like Outset, or management tools like puppet and munki may not get logged. The importance of auditing persistent items like cron jobs, rc scripts, launchd jobs, and startup items with inventory tools or host intrusion detection systems like osquery is just as important when 🎅 is in use. However, when in LOCKDOWN mode, the goal is to make the majority of attack vectors unavailable.
As this post is already huge I won’t yet be covering the only (actively developed) public server complement for 🎅, Zentral, so we’ll focus on client-side, standalone-type interactions. Again, out of the box, 🎅 does no blocking unless you tell it something to blacklist by populating a local rules database with the
santactl command line tool. This is MONITOR mode, and by default an asl config is provided to record all certificates seen and decisions made to a log file. It is recommended you collect these logs after a trial period to get the certs associated with the apps your organization uses to distribute as whitelist rule entries. I’ve done some reconnaissance on the matter by fetching about half of all of the downloads that have recipes in autopkg and made a searchable spreadsheet here. I’ve also made log-scrapers for both the certs and unsigned binaries I saw, along with an import tool that runs in parallel to shove in a whole bunch of rules at once.
Ready to eat some dogfood before deploying this to your fleet? (Really, this requires a healthy trial period to gather adequate data…) I’d recommend upping the asl.conf‘s total limits (the all_max= option), as in my experience it only can track about a week’s worth before rolling the logs over at 100MBs – we’re letting it grow to 500MBs. During that time I’d keep the Users Blacklist Regex in place (with nothing whitelisted to force as many prompts as possible) on admin workstations, as a kind of ‘LittleSnitch’-style way to more strictly police what runs on your system. You’ll also get a better understanding of all the poorly-written ShadowIT apps like GoToMeeting or Zoom.us(😱) that should either be destroyed or spayed/neutered.
Once you feel confident enough that appropriate rule criteria has been gathered, apply them to a limited test group (or shard) of the workstations you manage. Keep in mind that apps like Dropbox have unsigned components and setuid files that are leveraged per-user and could trigger a block notification, so staying on top of releases of anything else you discover is unsigned in your environment becomes that much more important.
Hopefully this toe-dip into 🎅 has been beneficial in getting folks to give it a try. I’ve made an internal-infosec-team focused whitepaper, with generic documentation for both admins and end users: hopefully this is a batteries-included, full tank of gas so you just need to start up the engine on the metaphorical 16-wheeler of awesome. You won’t really trust it or believe it’s maintainable without putting your own machine into LOCKDOWN mode and noticing how few (if any) alerts you receive once a small number of certs are whitelisted. Please feel free to leave comments here, file issues on Github, or ping their email list with questions.