Existing Kernel Extension policy not respected on update to 10.13
| Originator: | eholtam | ||
| Number: | rdar://39209026 | Date Originated: | 05-Apr-2018 11:18 AM |
| Status: | Open | Resolved: | |
| Product: | macOS + SDK | Product Version: | 10.13.4 17e199 |
| Classification: | Serious Bug | Reproducible: | Always |
Summary: Description: Start with 10.12.6 enrolled in MDM and has a Kernel Extension Policy (PayloadType = com.apple.syspolicy.kernel-extension-policy) whitelisting approved Team Identifiers (including G7HH3F8CAK for this example) delivered via the MDM. After upgrading to 10.13.4 (17E199) the MDM enrollment and KEXT profile are still installed and "Verified" per System Preferences->Profiles, yet when I try and load a KEXT from an approved vendor (Dropbox) I still get prompted by the system to allow the extension in the System Preferences. In this example I'm signing into Dropbox and enabling the Smart Sync capabilities which use a KEXT. The Team Identifier is G7HH3F8CAK and can be seen in the whitelist. The prompt to allow the KEXT should not appear and the KEXT should load automatically which is not happening. Steps to Reproduce: Steps: 0) Setup a computer with < 10.13.2 that has never run Dropbox before 1) Enroll the < 10.13.2 OS into MDM and apply a Kernel Extension Policy (PayloadType = com.apple.syspolicy.kernel-extension-policy) approving just the Team Identifier G7HH3F8CAK in this example. Choose whatever TeamID you have a KEXT for. 2) Upgrade the computer to 10.13.4 via App Store update 3) Authenticated restart signs the user back in after installing 4) Sign into a Dropbox account that has Smart Sync capabilities to have it load the KEXT Expected Results: The Dropbox KEXT would load during the setup process without user interaction since it is approved via com.apple.syspolicy.kernel-extension-policy. Actual Results: The system prompts the user to allow the Dropbox KEXT in System Preferences->Security during the setup process Version: 10.13.4 17e199 Notes: I setup a brand new machine using 10.13.4 as the starting OS, activating in DEP, enrolling in the MDM and getting the KEXT policy. KEXT policy _IS_ respected and does not prompt to allow TeamID whitelisted kexts. I upgraded a 10.12.6 machine with UAMDM and KEXT policy to 10.13.4, logged in as a user KEXT policy _NOT_ respected I upgraded a 10.12.6 machine to 10.13.4. Before logging a user in I restarted the computer again to verify it was a clean restart and not an authenticated restart from the installation process. KEXT policy _NOT_ respected I upgraded a 10.12.6 machine with UAMDM and KEXT policy to 10.13.4. Before logging a user in I made a change to the KEXT policy in the MDM, verified that 10.13.4 received the new MDM payload changes, then logged in as a user KEXT policy _IS_ respected Even though the 4th testing workflow resulted in positive results the process of having to change the MDM payload to get there is not acceptable but sheds some light on the issue.
Comments
Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!
+1
This is affecting us, as well.
From Apple:
From Apple: At this time, I don’t know if Product Engineering will be able to address this in an update to the High Sierra product. Your workaround may be the best way to address this in the near term.
If your fellow Mac admins are also running into this, please ask them to submit cases via their Enterprise Support contract.
If they don’t have a contract, their SE’s may be able to provide them with an incident so they can submit a case.