Sent "fileop_scope_callback" result to daemon for filtering? about santa HOT 6 CLOSED

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?

from santa.

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

from santa.

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.

from santa.

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?

from santa.

It's for executables only.

from santa.

OK, thanks again. :)

I'll close this issue now.

from santa.