Santa should provide an option to block apple system binaries and kill them automatically when launched

[ihateprogramming88]

1. Is it possible to provide an option to block apple system binaries and make it so that on boot they are killed?
2. For someone or others who don't use sirid, I have siri disabled but the daemon is launched on boot, it just takes space and if I am not using siri this daemon should stop being launched.
3. The same could apply for other apple daemons that a user do not use.

[russellhancox]

You can block Apple system binaries, using the binary SHA-256, the CDHash or a signing ID (with the prefix platform:). You should be very careful blocking system daemons though; even seemingly innocuous daemons can be responsible for surprising things and you can very easily get into a state where your system is unstable or hangs at odd times.

We do not, currently, attempt to kill already running processes. Issue #1291 is open to track possibly implementing this as a feature but it requires some thoughtful consideration as it can cause more problems than it solves.

[ihateprogramming88]

Wow quick response! Ah ha, I have been trying to block with the regularsantactl rule --blacklist --sha256 can you provide an example for blocking apple system binaries?

Do I have to revoke the rules I have already created without the platform: prefix?

1291 this seems like a good idea, but it would have to be optional.

[russellhancox]

This should do it:

santactl rule --block --signingid /path/to/binary

Do I have to revoke the rules I have already created without the platform: prefix?

No. You may want to, just so you know which rules are useful but it won't cause any problems at all.

[ihateprogramming88]

Unfortunately no luck with that command

`sudo santactl rule --block --signingid /System/Library/CoreServices/CoreLocationAgent.app/Contents/MacOS/CoreLocationAgent Unknown argument: /System/Library/CoreServices/CoreLocationAgent.app/Contents/MacOS/CoreLocationAgent

Usage: santactl rule [options] One of: --allow: add to allow --block: add to block --silent-block: add to silent block --compiler: allow and mark as a compiler --remove: remove existing rule --check: check for an existing rule --import {path}: import rules from a JSON file --export {path}: export rules to a JSON file

One of: --path {path}: path of binary/bundle to add/remove. Will add the hash of the file currently at that path. Does not work with --check. Use the fileinfo verb to check. the rule state of a file. --identifier {sha256|teamID|signingID|cdhash}: identifier to add/remove/check --sha256 {sha256}: hash to add/remove/check [deprecated]

Optionally: --teamid: add or check a team ID rule instead of binary --signingid: add or check a signing ID rule instead of binary (see notes) --certificate: add or check a certificate sha256 rule instead of binary --cdhash: add or check a cdhash rule instead of binary --message {message}: custom message --clean: when importing rules via JSON clear all non-transitive rules before importing --clean-all: when importing rules via JSON clear all rules before importing

Notes: The format of identifier when adding/checking a signingid rule is:

  `TeamID:SigningID`

Because signing IDs are controlled by the binary author, this ensures
that the signing ID is properly scoped to a developer. For the special
case of platform binaries, `TeamID` should be replaced with the string
"platform" (e.g. `platform:SigningID`). This allows for rules
targeting Apple-signed binaries that do not have a team ID.

Importing / Exporting Rules: If santa is not configured to use a sync server one can export & import its non-static rules to and from JSON files using the --export/--import flags. These files have the following form:

{"rules": [{rule-dictionaries}]}
e.g. {"rules": [
                  {"policy": "BLOCKLIST",
                   "identifier": "84de9c61777ca36b13228e2446d53e966096e78db7a72c632b5c185b2ffe68a6"
                   "custom_url" : "",
                   "custom_msg": "/bin/ls block for demo"}
                  ]}

By default rules are not cleared when importing. To clear the
database you must use either --clean or --clean-all

`

[russellhancox]

Ah, sorry, I missed an argument and forgot that the --path argument only works for SHA-256 rules (currently.. I'll fix this).

To block that particular daemon you can use:

sudo santactl rule --block --signingid --identifier platform:com.apple.CoreLocationAgent

[ihateprogramming88]

Awesome that worked :) Thank you!

[ihateprogramming88]

If you block apple binaries they still run how does this happen? For example if you block one locationd and santa will show a prompt saying it blocked it but in activity monitor it will still be listed.

[mlw]

In general, this shouldn't happen, however we'd need a lot more information to diagnose such a potential issue. What does your rule look like? What does the running process look like (i.e. are the properties of the running instance covered by the rule)? Was there already an instance running prior to Santa starting? Was Santa ever restarted (or crashed) allowing an opportunity for things like locationd to launch?

[ihateprogramming88]

Okay, it weird because for example the platform prefix with the Siri related daemons worked, but location d is still running so here is the rules I have related for them <E
platform:com.apple.locationd–.1U
platform:com.apple.CoreLocationAgent–J/Å, I am not sure exactly a better way to provide my santa.db file.

So there was not any errors or restarts related to santad, I just booted the laptop and it was running, for some related apple binaries santa blocks them and the GUI prompt displays.

[mlw]

The frameworks provided by Apple only provide the guarantee that applications like Santa have the opportunity to prevent non-platform binaries from executing during the so called "early boot" phase - that is, while the system is coming up and system daemons are being speculatively launched. Platform binaries will launch normally and if Santa hasn't yet started, they will execute without intervention. While Santa is configured to launch as early as possible, there are many platform binaries that will launch sooner. Looking at the PID in the screenshots, this seems likely what happened as those are pretty low PID numbers.

As mentioned by @russellhancox above, #1291 would help alleviate this issue, at least partially. But could definitely introduce other problems depending on what was being killed and when.

To check how Santa would evaluate a binary with your local rules, you can share the output of santactl fileinfo e.g.:

santactl fileinfo /usr/libexec/locationd