"System Extension Blocked" - Beta 2 - VMware Fusion

I am getting the following error pop-up when I try and install the latest version of Vmware fusion on High Sierra Dev Beta 2.


"System Extension Blocked" - A program tried to load a new system extension signed by "Vmware, Inc." and it was blocked. If you want to enable extension from this developer, go to the Security and Privacy System Preferences pane"


I don't however see anywhere under Secruity and Privacy to allow for system extensions. I do see the "Allow apps downloaded from" which is currently set for "App Store and identified developers"


Anyone else hitting this? Can anyone tell me how I can allow for the VMware system extensions on High Sierra. It appears that this is a new security control in High Sierra.


Thanks

I found this:

https://developer.apple.com/library/content/technotes/TN2459/_index.html#//apple_ref/doc/uid/DTS40017658


Problem is that I never see the "Allow" prompt as shown in this document. I immediately went into Security and Privacy right after the alert was fired. But the Allow prompt doesn't apper. Bug with this in beta 2 maybe??


Does anyone know how to manually approve a system extension via command line?


Thanks

For me this showed up under the Allow apps area. Just a button that I click to approve app extensions.

Right that is were you are supposed to find it. For the vmware fusion message it never shows for some reason. Wondering how to approve form CLI

I had the same problem, and the issue is that you should NOT close the warning dialog. If that is still open, the Security & Privacy pref pane will show as the developer note explains.

I had to reboot my VM to have the message re-appear.

Yes, I have this issue too. With the "Extension Blocked" notice still open, the control to whitelist it in Security & Privacy does not appear.

I'm not running as an administrator, which may or may not be related.


And I too am not able to reproduce the warning; haven't tried rebooting. I was trying to do a "sudo kextload", but didn't find a Fusion-related kext in {/System}/Library/Extentions. I didn't find any installed after the initial High Sierra install, in fact. Hm, did this block actually go as ar as to prevent the kext from being placed there?

Yes, one must be an admin user at this time to approve kexts. This is expected to change so that standard users will also be able to approve kexts, so the TN won't be changed from its current wording.


--gc

I fully understand the reasoning behind tightenig the security policy. But the whole user experience needs to be reviewed.


1. Users do not read dialogs, they often click out of them.

2. Users do not have the foggiest, what KEXTs are - and they should not have to know. Techno speak will not make the situation more secure.

3. Some KEXTs disabled as a result will not be requested to be loaded until days later. The request is hidden after 30 min. in the Preferences panel.


What I would suggest is a more open way of giving the users an easy way to review this. Apps need to have a simple way to trigger an intervention that is the same for all apps, so users have to train about this only once. The intervention should be triggered automatically, when the system is requested to load the extension. This might be via an app or IO event like a USB devices being plugged in.


The user should be able to gain a clear understanding of how to enable the KEXT again at all times.


KEXTs are an obtuse subject for most users. With our app we will get thousands of calls! This is not a good thing...


Given the rudimentary support on the UI and the limited way to query the issue from User Space, making this a good experience for our users is a real challenge.

I tried not closing the panel. No message either and no way to retrigger.

Good feedback. Can you please submit it as a bug report as that is the official channel and will make it to the right people that way?


Thanks,

--gc

I will do that tomorrow.


I have spent 1 1/2 days setting up a VM so I can checkpoint and experiment including using recovery mode to rescue a "Team" signature. I verified the time out of 30 min. noted in the TN and the only way to save is to use the Recovery mode spctl command.


There is no elegant way to prepare customers with our installers, although I will try. Phone support will be a challenge, most of the time we use remote admin or control to fix people's system, when it takes any complexity. That is not possible in recovery mode.


Thanks for being willing to listen. They are all of our customers.

Entered as suggestion #33547679.


I do wish, fields were not limited to 3K characters for suggestions.

If we are enduring this for improved security, does it make sense to allow non Admins to permit kexts?


I know that a lot of technical people run a non-admin account for added security. But I suspect, non-technical consumers will use an Admin account for themselves (it is after all the first account that gets set up,) and then have non admins for kids on shared or even dedicated machines. This allows for some level of control and protection from "stupid things." I would not want my young kids to install things or make choices in this regard.


Most installations ask for Admin privilege anyway,

It is december 2017 and it does not look like the issue is resolved.

I just agreed to Apple's offer to upgrade and now I have High Sierra 10.13.2.

Immediately after the upgragde is finished my VirtualBox and VMWARE Fusion stopped working.

That "Allow" button does nto apear for me regerdless of whatever I tried.

Try "sudo kextload" on the affected extensions, then check the Security planel.

"System Extension Blocked" - Beta 2 - VMware Fusion
 
 
Q