The following was filed as a suggestion in Apple's Bug Reporter. By adding it here, it might fuel ideas. Security is a tough challenge.
Input concerning KEXT-CONSENT TN2459
As described in TN2459 (kext consent) Apple is introducing a security change that will have a significant negative impact on the user experience. Since our product requires a KEXT, we are very concerned about this. This will lead to disruption in users trying to install and use our applications. In addition, the current recovery method for users not responding properly to the current UI flow will be extremely difficult to support. It might even lead to a reduction in security on many systems by support opting to disable SIP instead of adding a Team ID to the security policy, which requires dictating a complex string to a user. Let's remember that in a typical support situation, users are already flustered and support people are under time pressure.
First of all, let me state that I am in full support of increasing system security. I understand that even with signing of KEXTs by authorized developers, KEXTs represent a significant risk as a malware vector. However, I do not think that intervention or decision by the average user can help this issue.
In our testing and support experience with tens of thousands of users (our active user base exceeds 250k,) we have found that the majority do not read dialogs, especially if their wording does not make any sense to them. Many users click out of instructional videos, they close screens with tutorials. They do not click on Help buttons. Pro users and technical users tend to be different, but the majority of consumers like Mac because they do not have to know about technical issues.
When they see the currently proposed dialog, many of them will not fully understand its meaning and just click ok. I have thought about the wording and cannot think of a way to make it more understandable while retaining brevity. They are not likely to load the Security Preferences panel immediately. If they run into trouble with the app, we can guide them to the Security panel. But they might not use the app for 30 minutes and in that case the reference to "Allow" the extension will be gone!
They will call support and the current remedy is a daunting challenge. Very few users will have ever booted into the Recovery Partition. More importantly, these inexperienced users are usually helped via remote screen sharing. This is not possible in recovery mode. They will have to be guided to select the Terminal from the menu and then will be asked to type in a terminal command using a Team ID different from the warning dialog such as
spctl kext-consent allow GMTXYZA3F4 (not a real ID)
Support will then have to make sure, it was entered correctly by asking the user to type
spctl kext-consent list
and asking for the correct string to be read back. They will not know, whether this worked correctly until the system is rebooted and folks try to run the app. If an error was made, they need to start over. As I mentioned, I suspect many support people with hold queues will simply ask the customer to type
csrutil disable
We would all agree, this is undesirable. We will ask our support folks not to do this, but not everyone will be that disciplined.
More important, this is not an Apple Mac experience.
Here is my input in order of preference to help this situation:
- Reevaluate this feature altogether and look at alternatives.
I do not think that for the majority of users, their decision to allow a KEXT run will contribute to security. Personally, as a technical person I would like the notification. But most users cannot really make a knowledgeable decision. Alternate solutions to the issue would be proactive revoking of TeamIDs certificate with frequent system updates of root certificates or white listing known good KEXTs, which would require a registry. I would consider going all the way to proactive scanning for signatures of all kinds of malware. With my family I have gone to using BitDefender even on Mac to precent issues arising from social engineering etc. As an engineer and long term Mac user since 1984, this is distasteful, but just realistic. Having it built in would be seamless and not noticeable by users. - If you retain KEXT CONSENT, improve the user flow and management functionality. Instead of a separate notification dialog immediately bring up the Security Panel and use it to communicate the issue and allow users to OK in a simple way. Currently using two steps makes it much more confusing and requires locating the correct panel.
- Consider eliminating the 30 min. timeout altogether. It makes it impossible to recover in case of an error.
- Consider changing the Security Panel to add a section that lists all 3rd party KEXTs that either have consent (even if inherited from an upgrade) or are disallowed. Changing the state should be done with a simple check mark followed by a confirmation dialog. This has the following advantages:- It allows users and support to easily remedy a problem. - It allows for easily checking on known malware KEXTs without pulling up terminal and doing a kextstat | grep etc.
Would love to hear, what other developers are thinking.