macOS 10.14.5 Whitelists Kernel Extensions
Until 10.14.5, AppleKextExcludeLList.kext contained one Property List, KnownPanics.plist, which detailed kernel extensions known to Apple to be the cause of kernel panics, thus excluded from loading in Mojave; that hasn’t changed in 10.14.5. That kext now contains a second property list, ExceptionLists.plist, which is a long dictionary of “secure timestamp exceptions”.
Each entry consists of a string of hex digits, which is presumably an identifier or hash, together with the kext ID (such as com.thiscompany.mykext) and its version number. These appear to be an exhaustive list of over 18,000 existing kernel extensions which have been granted exceptions to the notarization requirement.
Previously:
- macOS 10.14.5 Requires New Developers to Notarize
- No NVIDIA Drivers for Mojave
- Kernel Extensions in High Sierra
- Apple Blacklists Its Own Ethernet Driver
- Apple Discourages Mac Kernel Extension Development
Update (2019-06-03): Howard Oakley:
The
manpage forspctlhasn’t been updated for over six years, but in 2017 it gained a set of actions to handle kernel extensions and your consent for them to be installed – what Apple terms User Approved or Secure Kernel Extension loading. You should be able to see these if you callspctlwith the-hoption. Thesekext-consentcommands only work when you’re booted in Recovery mode: they should return errors if you’re running in regular mode.This appears to unblock kernel extensions which macOS won’t install because they don’t comply with the new rules on notarization, presumably by adding the kernel extension to the new whitelist which was installed as part of the macOS 10.14.5 update. Kernel extensions which are correctly notarized should result in the display of the consent dialog taking the user to Security & Privacy; those which aren’t and don’t appear in the whitelist are simply blocked and not installed now.
Update (2019-08-13): Tom Bridge:
Whitelisting the Team ID in a Kernel Extensions payload from a User-Accepted MDM does not affect the notarization requirements in the Catalina betas at this time. What I said in the talk was based on my conversations with colleagues and friends, and an conversation I’d had with a member of Apple’s staff, and on my initial results with the first beta of Catalina.
My conclusions were based on the question I asked in that inteview: Will there be a way to whitelist Developer IDs for notarization the same way there is for Kernel Extension loading? The answer was an unequivocal yes.
I assumed that the method for this was the same payload. That has turned out not to be the case in my testing thus far.
[…]
Here’s what I do know: merely providing a kernel extensions whitelisting of the Team ID of a Developer is insufficient to prevent warnings for packages and disk images signed with that Developer Certificate.
2 Comments RSS · Twitter
the vice is tightening. soon kexts will be forbidden, taking away yet more control of our own computers.
