Hacker News Reader

Comment by Skunkleton | Hacker News Reader

You understand that Apple could bypass kexts too? This is an issue of trust, not a technical issue.

Try to bypass kexts and you’re just asking for kernel stability issues and Mac customer crashes. Pushing these guys out of the kernel lets Apple cheat them and Mac users clean and easy.

>Try to bypass kexts and you’re just asking for kernel stability issues and Mac customer crashes

why would that be the case? All you'd need to do is provide some sort of private network api, and only allow apple signed code to use it.

that is not how kexts work(ed), they can do completely arbitrary things to the kernel, including removing any theoretical code signing requirement.

any access? On Windows, you can write a driver that would run in kernel mode, but critical sections can't be modified[1]. I'd imagine there's something similar for mac.

[1] https://en.wikipedia.org/wiki/Kernel_Patch_Protection

KPP is not considered a security boundary. That means, in Windows security jargon, that it's a feature that helps security. But not something that you or anyone else should consider a fail proof solution, or even something that would result in a patch if breached.

If patching the kernel to intercept network requests is sufficiently hard enough that you're forced to use their "approved" way of intercepting network requests, then it's very easy for them to sneak requests through. Even if patching the kernel wasn't an issue, it still turns into a game of whack a mole because apple can sneak as many changes as they want with each macos release. It heavily favors apple, not the developers of such firewalls.

Even if patching the kernel wasn't an issue, it still turns into a game of whack a mole

Exactly - but the game itself is the problem. Firewall vendors will go hunting through kernel code for jump targets and structs to plug into hidden interfaces, and Apple will remove and change them, causing crashes and instability. Apple has some leverage if they have a program like WHQL, but even then driver writers will commit shenanigans. Push them out of the kernel altogether and now only Apple can engage in shenanigans and break user trust. Which they already have.

There hasn’t been anything like that on macOS. macOS on Apple Silicon will have a form of kernel patch protection, like on iOS, but it’s designed to guard against exploits from userland, not approved kexts. It’s definitely possible for third party kexts to bypass that somehow, but possibly only by disabling Secure Boot; I haven’t looked into it.

It's worth noting the Apple does release the source code to XNU (albeit on a ~6 month delay), and unlike some of their other source releases, there's actually enough tooling for you to build your own kernel. So while there are still gaps, it is overall more open to review.

Reply on news.ycombinator.com