4 ms·

Very informative. And presumably on OSX none of this applies because it's all BSD underneath? Or is OSX different again to just running BSD out of the box?

by urthor 5y ago

my123 5y ago
On macOS, you have those options: - SIP off (totally, or just driver signature enforcement) - kernel driver (deprecated, Apple doesn’t issue new certs anymore it seems) - system extension (user-mode driver, explicitly intended for device compatibility)
- deleted 5y ago
  [deleted]
- bpye 5y ago
  So whilst three is different aren’t the analogues on Windows for 1) and 2) 1) Test signing - do what you want 2) Kernel driver - still possible, needs EV cert?
  - my123 5y ago
    1) on Windows entails a significant security downgrade, as you cannot just pick custom kernel extension only, with validation by the user. That might however not be important, depending on your threat model. For 2), it’s borderline impossible to get a driver signing cert for macOS nowadays for individuals, it’s easier on Windows.
    - bpye 5y ago
      Ah yes, that is true, SIP is more granular than testsigning on Windows...
- grishka 5y ago
  And as far as I understand, disabling AMFI disables code signing support and enforcement completely.
  - my123 5y ago
    Disabling AMFI is a whole other level of a hammer, that I do not recommend at all on a system that you might actively use.
- jabedude 5y ago
  > Apple doesn’t issue new certs anymore it seems This is not true. kexts are still signed by apple after being submitted and vetted.
  - heavyset_go 5y ago
    Apple deprecated KEXTs[1], but still signs some .kexts they've chosen to grandfather in like macFUSE. [1] https://developer.apple.com/support/kernel-extensions/ https://developer.apple.com/support/kernel-extensions/
    - JonathonW 5y ago
      Kexts are not deprecated in general-- only kexts that use deprecated KPIs are deprecated. (The page you link is the list of deprecated KPIs.) The net effect of this: if something can be done using a System Extension rather than a kernel extension, you'll get deprecation warnings if you try to do it with a kernel extension. Kernel extension points that have not been replaced yet are still valid, will still be signed if used, and will still run on current versions of macOS.
- seltzered_ 5y ago
  Also, if there is non-profit org work, recall that one can supposedly setup an organization and request a developer fee waiver: https://developer.apple.com/support/membership-fee-waiver/ https://developer.apple.com/support/membership-fee-waiver/ (no idea how this actually works in practice, wonder if one could wrap open source work under a non-profit organization)
native_samples 5y ago
On Mac it's significantly more locked down and judging from recent comments by Tim Cook they still aren't happy with it. Presumably they see iOS as the gold standard internally and would love to make OS X work the same way, but can't without breaking too many apps. The recent stance taken by the judge on Epic v Apple re: Gatekeeper will certainly push them further in the lockdown direction :( On OS X Intel the operating system will basically refuse to run unsigned code unless you know an ever-shifting series of magic undocumented cheat codes. You have to do weird things like hold down certain keys then use the right click context menu to open unsigned apps, you need magic CLI commands to disable notarization checking, you have to go into the system preferences window to enable drivers to be approved and then reboot etc. The UX is atrocious and gets worse all the time - it's barely acceptable even for developers. That's for usermode. Kernel mode drivers are dead now, more or less. On OS X ARM unsigned code will not run. Period, end of story. The magic cheat codes are gone. All code must be notarized, which is a server-side approval process of the type Microsoft only use for kernel drivers. There are a few silver linings to all this. One is that getting a cert isn't actually that hard. You need a credit card, basically. It's not like getting an EV cert where you need a company and for a CA to verify the corporate identity. Likewise their "notarization" process is not a manual app store like review, it's fully automated and is mostly just checking that the app is well structured and properly signed. It probably does other things like checking you aren't using internal APIs, and they presumably archive all the binaries they notarize so they can go back in time to investigate malware and so on. But it's not being used for political or commercial purposes, at this time.

Very informative. And presumably on OSX none of this applies because it's all BSD underneath? Or is OSX different again to just running BSD out of the box?

by urthor 5y ago

Very informative. And presumably on OSX none of this applies because it's all BSD underneath? Or is OSX different again to just running BSD out of the box?

my123 5y ago

On macOS, you have those options: - SIP off (totally, or just driver signature enforcement) - kernel driver (deprecated, Apple doesn’t issue new certs anymore it seems) - system extension (user-mode driver, explicitly intended for device compatibility)

deleted 5y ago
[deleted]
bpye 5y ago
So whilst three is different aren’t the analogues on Windows for 1) and 2) 1) Test signing - do what you want 2) Kernel driver - still possible, needs EV cert?
- my123 5y ago
  1) on Windows entails a significant security downgrade, as you cannot just pick custom kernel extension only, with validation by the user. That might however not be important, depending on your threat model. For 2), it’s borderline impossible to get a driver signing cert for macOS nowadays for individuals, it’s easier on Windows.
  - bpye 5y ago
    Ah yes, that is true, SIP is more granular than testsigning on Windows...
grishka 5y ago
And as far as I understand, disabling AMFI disables code signing support and enforcement completely.
- my123 5y ago
  Disabling AMFI is a whole other level of a hammer, that I do not recommend at all on a system that you might actively use.
jabedude 5y ago
> Apple doesn’t issue new certs anymore it seems This is not true. kexts are still signed by apple after being submitted and vetted.
- heavyset_go 5y ago
  Apple deprecated KEXTs[1], but still signs some .kexts they've chosen to grandfather in like macFUSE. [1] https://developer.apple.com/support/kernel-extensions/ https://developer.apple.com/support/kernel-extensions/
  - JonathonW 5y ago
    Kexts are not deprecated in general-- only kexts that use deprecated KPIs are deprecated. (The page you link is the list of deprecated KPIs.) The net effect of this: if something can be done using a System Extension rather than a kernel extension, you'll get deprecation warnings if you try to do it with a kernel extension. Kernel extension points that have not been replaced yet are still valid, will still be signed if used, and will still run on current versions of macOS.
seltzered_ 5y ago
Also, if there is non-profit org work, recall that one can supposedly setup an organization and request a developer fee waiver: https://developer.apple.com/support/membership-fee-waiver/ https://developer.apple.com/support/membership-fee-waiver/ (no idea how this actually works in practice, wonder if one could wrap open source work under a non-profit organization)

native_samples 5y ago

On Mac it's significantly more locked down and judging from recent comments by Tim Cook they still aren't happy with it. Presumably they see iOS as the gold standard internally and would love to make OS X work the same way, but can't without breaking too many apps. The recent stance taken by the judge on Epic v Apple re: Gatekeeper will certainly push them further in the lockdown direction :( On OS X Intel the operating system will basically refuse to run unsigned code unless you know an ever-shifting series of magic undocumented cheat codes. You have to do weird things like hold down certain keys then use the right click context menu to open unsigned apps, you need magic CLI commands to disable notarization checking, you have to go into the system preferences window to enable drivers to be approved and then reboot etc. The UX is atrocious and gets worse all the time - it's barely acceptable even for developers. That's for usermode. Kernel mode drivers are dead now, more or less. On OS X ARM unsigned code will not run. Period, end of story. The magic cheat codes are gone. All code must be notarized, which is a server-side approval process of the type Microsoft only use for kernel drivers. There are a few silver linings to all this. One is that getting a cert isn't actually that hard. You need a credit card, basically. It's not like getting an EV cert where you need a company and for a CA to verify the corporate identity. Likewise their "notarization" process is not a manual app store like review, it's fully automated and is mostly just checking that the app is well structured and properly signed. It probably does other things like checking you aren't using internal APIs, and they presumably archive all the binaries they notarize so they can go back in time to investigate malware and so on. But it's not being used for political or commercial purposes, at this time.