4 ms·

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

by throwaway2048 6y ago

gruez 6y ago
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 https://en.wikipedia.org/wiki/Kernel_Patch_Protection
- SCHiM 6y ago
  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.
  - gruez 6y ago
    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.
    - CountSessine 6y ago
      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.
- comex 6y ago
  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.

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

gruez 6y ago

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 https://en.wikipedia.org/wiki/Kernel_Patch_Protection

SCHiM 6y ago
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.
- gruez 6y ago
  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.
  - CountSessine 6y ago
    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.
comex 6y ago
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.