Google Drive File Stream - System extension on Big Sur?

[quip_MDavison]

So we currently deploy the Google Drive File Stream client to our workstations. According to the October changelog the application "supports Big Sur," but in testing our previous policies to preapprove the kernel extension for the app obviously no longer works. The app prompts to install a system extension which must be done by an admin user and then prompts for a reboot as expected with the new behavior but when you log back in and run "systemextensionsctrl list" it still says no system extensions found so we can't get the proper app/team IDs to pre-approve with a JAMF payload.

Anyone else run into this, or just happen to have the proper IDs? Are they the same as the old kernel extension?

[tcandela]

I just downloaded Google Drive for Desktop on a 13" MBPro M1 and ran the .pkg and it never asked me to approve any system extensions.  I logged into my google drive so the drive would mount and I did not get any system extension prompt to allow anything. 

I restarted the laptop and nothing, no prompts.  The version reads Google Drive version 51.0.14.0 (Apple Silicon)

I run the 'sysemextensionsctl list' and it says 0

when you download google drive does it know whether to download the M1 version of Intel version?  Is there 2 separate versions?

[quip_MDavison]

That's correct, the Apple Silicon version no longer requires any sort of System Extension or Kernel Extension.

It's a "universal" app package, so both the Intel and M1 version of the app are rolled together into one pkg and it automatically detects which version should be installed based on the system architecture.

As of this time the Intel version still requires a System/Kernel extension.  On Catalina (and lower) installs we can pre-approve this via configuration payload, but that no longer works for Big Sur.  So for Intel machines running Big Sur the current behavior is that direct user action is required to approve the extension the first time you run Drive File Stream, and that user must have admin rights.

[tcandela]

@quip_MDavison what do you have for your intel Catalina/Big Sur extension. config profile? 

[quip_MDavison]

Here's what we use for our Catalina Intels and it still works.  This issue actually stopped us from rolling out Big Sur entirely until we could make the jump to start deploying M1 Macs, there's no way to do it by config profile or policy on a Big Sur Intel machine and Google has no interest in going back to resolve it.  There were lots of back and forth support calls with Google about it...  It took Google nearly a year to re-engineer the app not to require a system extension anymore.  Should be fun in a few months when Monterey manages to jack it all up again 😛

[tcandela]

@quip_MDavison yep I have the same Catalina KEXT config profile setup as you.  Just tried it to verify with Google drive v 51.0.14.0 and not prompt to allow after logging into the google drive account.

[GregE]

I thought Kernel Extensions were for Catalina, System Extensions were for Big Sur or have I missed something? That profile above shows a Kernel Extension applying successfully for Big Sur?
https://developer.apple.com/support/kernel-extensions/

[quip_MDavison]

You are correct.  We have the policy above scoped explicitly to apply to Catalina machines, not Big Sur.

Catalina Intel: The above payload works for pre-approving the GDFS kernel extension
Big Sur Intel: The above payload does not work, in fact it gives an error when trying to apply if you look at the logs.  Using a system extension payload does not work either, and even trying to get the values to put in the system extension payload off a GDFS install on these systems is a challenge.  Per Apple's security changes there is no way to pre-approve a system extension via MDM controls on Intel Macs running Big Sur.  Direct user action with admin rights is required to approve the legacy extension when prompted on first run.
Big Sur M1: The Apple Silicon binary for GDFS was re-engineered (as of a recent version, around June/July 2021 IIRC)  to no longer require a system or kernel extension, just deploy the pkg and it works.  Yay. Before that update it was in the same boat as the Big Sur Intels where you could not preapprove the system extension via MDM and the old kernel extension no longer worked.  They did not go back and do the same for the Intel binary, and from my talks with Google engineering support they don't have any plans to do so.

[PaulHazelden]

If you create a PPPC profile for Drive, you can make it so that a standard user can authorise the system/kernel extension, rather than an Admin. I have it running on the Big Sur Macs both Intel and M1, and the students can approve the extensions themselves when it asks.

[quip_MDavison]

You can, but it's kind of a kludgy workaround where the user still has to go through the prompts and allow it.  It also raises some security concerns we weren't comfortable with in our environment 😛

[tjhall]

@Greg That's what confused me too. I was under the impression that Big Sur only used system extensions but kernel extensions are still used for Intel Mac's but not on M1's. Hence the confusion with config profiles and having to split them depending on architecture.

[MLBZ521]

Please see my previous replies:

• https://community.jamf.com/t5/jamf-pro/google-drive-file-stream-system-extension-on-big-sur/m-p/2252...
• https://community.jamf.com/t5/jamf-pro/google-drive-file-stream-system-extension-on-big-sur/m-p/2447...

KEXTs are available on Catalina and Big Sur on both Intel and ARM devices.  For them to work on ARM they HAVE to be recompiled.  Rosetta will not translate them.

SysExts are available on Catalina and Big Sur on both Intel and ARM devices.

The "warning dialog" that is thrown up IS NOT ACCURATE.  It will say a System Extension is blocked, even when it is a Kernel Extension.  The warnings for each are actually different, but both still say "System Extension."

[TimDearborn]

I had the install for Google Drive for Desktop working for non-admin users on Intel machines running Big Sur, but now the install is not working anymore. I have not been able to figure out why the install stopped working. Specifically, the Allow button is no longer displaying in the System Preferences -> Security & Privacy -> General tab. As a result, there is no way for users to approve the Google Drive kernel extension for Intel machines.

I am running 11.6 on Intel and Google Drive for Desktop 51.0.15. I have a kernel Extension Profile allowing the Google teamID for Drive (EQHXZ8M8AV). This profile also allows non-admin users to approve kernel extensions.  For good measure, I have a System Extension profile allowing users to approve system extensions and am allowing the Google team ID EQHXZ8M8AV.

Is anyone else able to push the install of Google Drive 50.0.15 on an Intel machine where users can allow the Kernel extension?

[quip_MDavison]

I actually just had this crop up in our environment, exact same scenario.  We were able to manually trigger the system extension prompt in Security & Privacy > General by restarting Google Drive so it would prompt again and then clicking a sneaky pop-under box from Google Drive about an "updated" System Extension that needed to be clicked before it would show up in the Security & Privacy menu to approve.

Looks like Google did something to update/change their system extension for the Intel version of the app and it broke our preapproval config profile.  It likely has a new ID or something that we need to go fishing for.  I'll have to see if I can recreate it in the lab to get some updated values or if it's just going to remain broken moving forward.

Never a dull moment!

[tcandela]

anyone have a working system extension for Google drive for desktop for Big Sur?

after i go through all the system extension prompts to allow it i then go to terminal and put in

'systemextensionsctl list'  and it says 0 extensions

[Geissbuhler]

If anyone finds this helpful I have modified the download and Install google Drive script to not show the end user the mounted drive during install, works well.

Not sure if the Bless part I added does anything for this app, but works for removing the message (paraphrasing) "This was Downloaded from the internet are you sure you want to use this"

Replaced hdutil mount command with attach and added the -nobrowse flag:

#!/bin/zsh

# make temp folder for downloads
mkdir "/tmp/googledrive"

# change working directory
cd "/tmp/googledrive"

#download Google Drive File Stream
curl -L -o "/tmp/googledrive/GoogleDrive.dmg" "https://dl.google.com/drive-file-stream/GoogleDrive.dmg"

# Mount the DMG
hdiutil attach GoogleDrive.dmg -nobrowse

# Get Volume Name
Volume=$(diskutil info / | grep "Volume Name:" | awk '{print $3,$4,$5,$6}')

# Install Google Drive
sudo installer -pkg /Volumes/Install\ Google\ Drive/GoogleDrive.pkg -target /

#Tidy Up
hdiutil unmount "/Volumes/Install Google Drive"
sleep 5
sudo rm -rf "/tmp/googledrive"
sleep 5

#Bless Google Drive app
xattr -rc "/Applications/Google Drive.app"