This article serves as a guide on deploying Google Santa via Addigy and using commands to create rules.
Note: This process is macOS-specific.
TABLE OF CONTENTS
- Custom/Smart Software
- Deploying PPPC/System Extension Whitelistings
- Working with Santa through Addigy
- Blocking Bundle Hashes vs. Blocking Certificates
Disclaimer: Santa is a powerful blocking tool, and we recommend testing it, prior to deploying it on production devices to understand the impact of blocking specific applications. Please thoroughly test within a staged environment for expected results.
Custom/Smart Software
Google Santa deploys via PKG, which can easily be uploaded into Addigy as a custom software item. If done via custom software, your item should look similar to the below:
Deploying PPPC/System Extension Whitelistings
1. Google Provides their own .mobileconfig files for PPPC and System Extensions. These are attached at the bottom of the KB article.
2. After downloading the needed files, upload them both to Addigy as Custom Profiles and deploy them to your device(s). Instructions on this process can be found here: How To: Configure and Deploy a Custom MDM Profile
We highly recommend deploying the PPPC and System Extension .mobileconfig files to your devices before deploying Santa.
Working with Santa in Addigy
Santa uses commands run on the device to manage rules locally on devices. This means that commands can be sent directly from Addigy to update these rules (block, allow, modify).
Santa uses a binary located in /usr/bin/local/santactl to invoke commands, which will become our prefix when running commands from Addigy.
Obtaining File Info Using Santa
Santa allows you to obtain all relevant file info for blocking or allowing using the fileinfo command. To call this from Addigy, the command is run as:
/usr/local/bin/santactl fileinfo Path/To/File
Below is an example of this command run for Skype. Highlighted in blue is the bundle hash, and highlighted in yellow is the certificate hash:
Applying a Rule
Once the file's hashes are received, we can create a rule to block it. Later in this article, we will discuss whether to block the Bundle Hash or the Certificate hash.
Santactl's rule command has several flags:
- Allow: add to allow list
- Block: add to block list
- Silent-block: add to block list (without pop-up when a block occurs)
- Remove: remove existing rule
-
Check: check for rule
- --path: The path will go to the specified location and grab the hash of that specific file, which is handy if creating rules for the current versions on the device.
- --sha256: Apply the rule to the given hash. Blocking the hash manually can be done without the file being present on the device.
Optionally:
- --certificate: Used to specify if the hash given is a certificate. This will apply to all items signed with the same certificate, which can be used to block several applications from the same developer.
- --message: Used to specify the message given to the user when an application is blocked.
Below is the command that would be used if we wish to block Skype's Bundle Hash from the above example, with a custom message:
/usr/local/bin/santactl rule --block --sha256 735f9396f23d1a750bc20f5015b8c45714767589d3fed867f6188a9ce624100a --message "Skype is not allowed within this device policy."
Once applied, the above command will cause the following user prompt when Skype is blocked:
Similarly, to remove the above block, the same command can be run but using the --remove flag instead of --block (The --message flag is no longer needed as the rule is being removed):
/usr/local/bin/santactl rule --remove --sha256 735f9396f23d1a750bc20f5015b8c45714767589d3fed867f6188a9ce624100a
Blocking Bundle Hashes vs. Blocking Certificates
At first, these two options may seem like they have the same behavior, but they both have very different effects depending on what you wish to block.
Bundle Hashes are unique to each .app version. This means if an application is blocked via Bundle Hash, it will only block that version of the .app. If a newer version of the file/software is present, this will not be blocked until a new rule is added.
Certificates are a signature of the developer that has released the software. Blocking a certificate will effectively block all versions of the software blocked and block all other applications signed with that certificate. This can cause adverse effects if the device uses other items signed by the same certificate. For example, blocking a native macOS Application via certificate will effectively block all Apple software from the device.
Blocking items by Certificate is very powerful and may have adverse effects if the same certificate is used for other items. Please exercise caution when blocking items by certificate, and if possible, test before deploying to production devices.