|
|
|
|
|
by derefr
1934 days ago
|
|
You already have to reboot into the Recovery environment and disable both System Integrity Protection (with csrutil) and OS root-volume signing (with bputil) in order to even (persistently) modify any of the files in /System now. Malware can't do that, because there's no way for any executable that runs in the regular OS—and isn't signed by Apple—to get anything to automatically happen over in the Recovery OS. (That's not to say you can't have persistent malware in macOS; just that it can't persist itself into the OS boot volume. It has to persist into the user volume—which is great, because that means the OS can, on boot, mount the user volume noexec and scan it for malware while running in a known-good base state. That's even without needing to boot into the recovery OS.) So, other than OS updates, basically the only reason these files get modified is when people modify them manually. And the only people doing that are 1. people developing kernel extensions (or their friends, the Hackintosh community); and 2. enterprises burning low-level configuration changes into OS images for image-based deployment. And both of those cases involve modifying things that are effectively "underneath the OS API abstraction", and therefore don't have the same ABI guarantees that the OS APIs themselves do. Thus the whitelist. |
|