santa daemon should have a mechanism to prevent being killed by users with root privileges.

[izzh]

If I have root privileges, I can bypass the allowlist mechanism by repeatedly killing santa daemon in a loop.

#!bin/bash

while true; do
    ps aux | grep com.google.santa.daemon | grep -v grep | awk '{print $2}' | xargs kill -9
    if [ $? -eq 0 ]; then
        echo "kill santa daemon"
    fi
    sleep 0.5
done

santa@macos-13 Desktop % ./process_not_in_allowlist
### Before run the kill script
Santa

This application has been blocked from executing.

Path:       /Users/santa/Desktop/process_not_in_allowlist
Identifier: 0b742eae49b08af3858f17e95aa80afa82a18a178a671fc23256f12d58286894
Parent:     zsh (2021)

More info:
https://santa/blockables/E6C3C62D-8A40-5B56-99CA-191EACBCE8FD/0b742eae49b08af3858f17e95aa80afa82a18a178a671fc23256f12d58286894

### After run the kill script
santa@macos-13 Desktop % ./process_not_in_allowlist
malicious
^C
santa@macos-13 Desktop % ./process_not_in_allowlist
malicious
^C
santa@macos-13 Desktop % ./process_not_in_allowlist
malicious
^C
santa@macos-13 Desktop % 

I have observed other security software that cannot be killed even if I have root privileges.

santa@macos-13 Desktop % ps aux |grep falcon
root               375   5.5  0.7 36057876 228704   ??  Rs   Mon04PM 124:01.29 /Library/SystemExtensions/EA9DEA93-1AAA-4A86-9DC4-9CA95609D798/com.crowdstrike.falcon.Agent.systemextension/Contents/MacOS/com.crowdstrike.falcon.Agent
santa@macos-13 Desktop % sudo kill -9 375
Password:
kill: 375: Operation not permitted
santa@macos-13 Desktop ~ % 

Is it possible to implement a feature to control whether santa daemon can be killed through a configuration field? thanks～

[mlw]

Santa currently has some basic tamper resistance features, but we should expand upon these, including better signal handling. It is something we'd like to get to eventually.

While handling signals is definitely doable, it does have some tricky edge cases that need to be cleanly handled. The kill command mentioned is one way but there are other, more complicated scenarios. launchctl kill/launchctl kickstart are other ways to send signals and these get sent via launchd. Properly discerning this from valid things like system shutdown or system extension (e.g. Santa) upgrade takes some effort.

It's worth noting the more something is locked down, the more difficult it is for field support and unblocking users in weird states. As suggested, gating the level of headache an admin wants to enjoy behind config options could be one way to better stomach stronger tamper resistance mechanisms.