Endpoint Security Framework and signals

App & System Services Core OS
kithrup OP
Created
Replies 3
Boosts 0
Views 952
Participants 2

I added ES_EVENT_TYPE_AUTH_SIGNAL to the event list, and added logging:

os_log_debug(esfLogger, "antitampering signal %d from process %{public}s to process %{public}s", esm.signal, signing.UTF8String, targetSigning.UTF8String);

I get some logs, such as

2024-12-09 10:21:47.668034+0000 0xc2c562   Debug       0x0                  29448  0    DopeMonitorService: [security.dope:anti-tamper] antitampering signal 0 from process com.apple.spindump to process com.apple.mds_stores

But when I do sudo kill -9 ${ourappprocess}, the proess dies with no log generated. (This is a different process than the one using ESF; the goal is, obviously, to keep our processes from being killed, but I'm only at the logging stage so far.)

sudo kill -INFO ${ourappprocess} works:

2024-12-09 10:21:38.410851+0000 0xc2c562   Debug       0x0                  29448  0    Monitor: [debug:anti-tamper] antitampering signal 29 from process com.apple.csh to process Worker

So it is getting through to the monitoring process. But kill -9 ... isn't. Am I missing something obvious again?

Answered by DTS Engineer in 817400022

Honestly, that seems bugworthy.

Before you file this, I recommend that you try replicating with eslogger. If you can, that rules out any possibility of your code being at fault.

Please post your bug number, just for the record.

ps I can see how this might happen because SIGKILL isn’t delivered, kinda by definition. However, I can also see why as an ES product you’d want to be able to authorise SIGKILL, hence my advice.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Replies  3
Boosts 0
Views  952
Participants  2
DTS Engineer OP
Apple
Recommended

Honestly, that seems bugworthy.

Before you file this, I recommend that you try replicating with eslogger. If you can, that rules out any possibility of your code being at fault.

Please post your bug number, just for the record.

ps I can see how this might happen because SIGKILL isn’t delivered, kinda by definition. However, I can also see why as an ES product you’d want to be able to authorise SIGKILL, hence my advice.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
kithrup OP

I was very curious why I'd never seen eslogger and it turns out it's because it was introduced more recently than my older systems. 😄

Confirmed that it shows the expected behavior on one machine, so I'll be poking at it. At least I know that it does show SIGKILL actions. Although I guess that's notification, not authorization...
kithrup OP
Accepted Answer

AH HA! I have found two problems!

  1. I had it set to cache the results, which resulted in no more auth messages.
  2. I convert the messages to an ObjC class, and for the process initialization, I'd forgotten to initialize the pid property. This resulted in all processes having a pid of 0, which of course I skipped because that's the kernel! (I allow launchd, aka pid 1, to send signals. Things get bothersome otherwise.)

PEBKAC FOR THE WIN! 😄

This took a long time to diagnose because it's a bad idea to use breakpoints on a process that is using ESF for authorizations.