Sent "fileop_scope_callback" result to daemon for filtering?

[x43x61x69]

Hi,

First, you guys rock! It's so amazing and nicely coded project.

I understand that the purpose of Santa was for executable scanning. However, some files are not directly executables. I was trying to filter files by sending the FILEOP scope results to the daemon for filtering, but the system freezed once the kext was loaded. (I do always return KAUTH_RESULT_DEFER as Apple's suggested on FILEOP scope. But seems the action of sending messages from that scope to the daemon will cause the freeze. I haven't been able to retrieve the log as the system will freeze again on the reboot, and I haven't been able to get into single user mode in a VM.)

Have you guys try something like that and decided not to do so because the performance was bad? Or there were other limitations regarding the system itself on "on access" filtering?

Best,
Cai

[russellhancox]

I'm in the middle of adding file-modification logging right now (see master...russellhancox:master).

What sort of filtering are you interested in doing?

[x43x61x69]

As someone found out that the dynamic library injection could bypass the Santa detection as they are not considered within KAUTH_SCOPE_VNODE, they could still be catched if we use the FILEOP scope with KAUTH_FILEOP_OPEN. (Which will cause deadlock according to Apple TN2127.)

I tried to feed the message from the fileop_scope_callback() into GetResponse() like the VNODE callback does. The system will freeze if I do this, tho KAUTH_FILEOP_CLOSE with KAUTH_FILEOP_CLOSE_MODIFIED would not cause this issue, but wouldn't get the result I wanted. (Catch the dylib as dyld still need to read the file before it can be load into the main binary.)

Hope my English is understandable. :p

[russellhancox]

Gotcha. The problem with that is the result of the Fileop callback is always ignored, so you can't block a file that way and blocking fileop while waiting for a result in userspace is almost guaranteed to deadlock anyway, as TN2127 says.

On top of that, for the specific issue of whitelisting dylib's, there isn't a way of differentiating between an open by dyld and an open by say "cp" or "mv" or "installer". If you just wanted to log (rather than block) dylib opens it might be possible to put something in fileop_open that reads the first page of the file in kernel space and checks its file type and logs the name and pid of the opening process.

[x43x61x69]

Thanks for the reply. I did understand that we can't block the dylib, but we can "fix" (either patch it back or damage) it so it can't be load by dyld. (At least that's what Apple told us.) As we tapped on the vnode scope, we will know if there's a script running to do the injection or via sh etc. We can also get the script file path so if it's a known malicious script/dylib sha256, even that we can't stop it from running, we can still guess what files has been modified after it started, better than nothing.

I'm able to log the path of the dylib via KAUTH_FILEOP_OPEN, but seems sending everything to the daemon is way too much work for it to handle. I haven't try to do the file type directly in the kernel space tho, might be a better way as it's a bit better than let the daemon to do all the work. Will try that later.

Is Santa going to implement the "on access" scanning feature in the future? Or it's for executable only?

[russellhancox]

It's for executables only.

[x43x61x69]

OK, thanks again. :)

I'll close this issue now.