Managing Google Chrome Auto Updates

Google Chrome has a few ways in which you can manage its update mechanism which I wanted to post about.

Google Chrome Enterprise Installer

If you’re not already doing so, I recommend you start using the enterprise Google Chrome installer package. This package installs Google Chrome but also configures the Google Software Update Agent which many admins were doing with a separate script. Once Chrome is registered with the Google Software Update agent, there’s a few options for managing it to ensure that Google Chrome stays up to date.

Managing Google Software Update/Keystone

Here is an article that talks about how to manage Google Chrome updates: https://support.google.com/chrome/a/answer/7591084

By generating a configuration profile that manages the domain com.google.Keystone.plist, you can ensure that Google’s auto update mechanism is configured according to your needs. Keep in mind that the Google Software Update Agent can manage the updates for various Google apps on macOS. Unfortunately, the Google Software Update Agent won’t necessarily force users to do anything as it’s pretty transparent in the background and its job when unmanaged is just to check for updates and stage them for installation on a relaunch of a Google application. Once a registered Google application is relaunched, it will ensure the app is running the latest version.

Managing Update Notifications

Fortunately, Google has provided a way for admins to notify users that a Chrome update is pending and force them to relaunch. This article talks about how to manage relaunch notifications: https://support.google.com/chrome/a/answer/7679871?hl=en&ref_topic=9023245

RelaunchNotification

Tells users to relaunch Chrome Browser or restart their device running Chrome OS to get the latest update. Choose one of the options:

Relaunch recommended—Users can close the notification and keep using the old version of Chrome Browser or Chrome OS until they choose to relaunch Chrome Browser or restart their Chrome device.
Relaunch required—Users can close the notification but will see a recurring message that Chrome Browser will automatically relaunch or their Chrome device will restart after a certain time. Use the RelaunchNotificationPeriod policy to set the relaunch time (details below).

Unset: On the toolbar, the More icon More changes to indicate that an update is available but users aren’t forced to relaunch.

RelaunchNotificationPeriod

Sets the time period, in milliseconds (ms), that a user is repeatedly notified to relaunch Chrome Browser or restart their Chrome device to apply an update.

Unset: The default time period is 604,800,000 ms (7 days).

In our environment, we’ve got it set to  86400000 ms (or 24 hours). It has worked out pretty well for us. As an aside, I have no idea why Google chose to work with milliseconds.

Here is an example screenshot of what the notification looks like in Google Chrome if you set it to require a relaunch in 4 days:

Screen Shot 2019-06-21 at 9.39.38 AM

When does Google Software Update run?

The last part of the equation to account for is controlling when Google Software Update Agent runs. At the moment, there is no way to do so. Google Software Update Agents runs based on a launch daemon in /Library/LaunchDaemons/com.google.keystone.daemon.plist and 2 launch agents in /Library/LaunchAgents/com.google.keystone.agent.plist and /Library/LaunchAgents/com.google.keystone.xpcservice.plist.

Here are my observations:

  • The agent will automatically check for updates when the user logs into macOS.
  • The agent will automatically check for updates when Google Chrome is launched. However, it will only install any updates after a relaunch of Chrome.
  • The agent is supposed to automatically check for updates every 3623 seconds (this may be randomized on each device). As someone who does not use Chrome, I found that the app remained unpatched for days even when updates were definitely available which leads me to believe that this is not checking aggressively enough or there are some strings attached. I purposely did not launch Chrome to see how long it would take for it to auto update.

This becomes a bit of a problem because most people rarely restart their web browser, let alone log out and log back into their computer. I wanted a more guaranteed way that would ensure that Chrome was at least regularly checking for updates in the background. The idea here is if someone is not using Chrome then I want it to be updated as soon as they do decide to launch it the next time. I don’t want to try and check for updates in the background only when the browser is launched.

I did a bit of searching and found the following discussion on Jamf Nation which shows you can run the following command as the user (it will not work if you run this as root or a user other than the one in the current session):

"/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/GoogleSoftwareUpdateAgent.app/Contents/MacOS/GoogleSoftwareUpdateAgent" -runMode oneshot -userInitiated YES "$@"

That eventually led me to create a launch agent that I could then deploy myself to devices:

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”&gt;
<plist version=”1.0″>
<dict>
<key>Label</key>
<string>com.company.google.softwareupdatecheck</string>
<key>LimitLoadToSessionType</key>
<string>Aqua</string>
<key>ProgramArguments</key>
<array>
<string>/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/GoogleSoftwareUpdateAgent.app/Contents/MacOS/GoogleSoftwareUpdateAgent</string>
<string>-runMode</string>
<string>oneshot</string>
<string>-userInitiated</string>
<string>YES</string>
<string>”$@”</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>StartInterval</key>
<integer>21600</integer>
</dict>
</plist>
I was able to push this out through a simple package that installed this at /Library/LaunchAgents/ with permissions set to 644 and owner/group set to root:wheel. The idea here is that the launch agent will run every 21600 seconds (or 6 hours). I chose 6 hours because it would at least ensure that the Google Software Update agent checks for an update at least once a day during the work day. Feel free to change those values for yourself.
If you think I missed anything or have something useful to add, feel free to write in the comments. I hope you’ve found this at least somewhat informative.

The Importance Of Filing Feedback During Major OS Releases From Apple

It’s not going to be too long before Apple releases macOS Mojave 10.14. They’ve announced it’s release for Fall 2018 at WWDC earlier this year. On August 13, 2018, they released beta 7 and on August 20, 2018 they released beta 8 which indicates they might be making weekly releases up until the general public release of 10.14. Based on previous release dates for macOS, my guess is that Apple will release macOS 10.14 sometime in late September.

Beta testing

If you’ve been part of the beta program and you are in charge of managing Macs in an enterprise environment then hopefully you’ve been providing feedback to Apple about the issues you’ve been running into. If you are not a part of the developer program, then you should join it and provide feedback. You can even have your fee waived for the developer program in certain circumstances. Alternatively, you can also join the Apple Beta Software Program. Even better, if you haven’t already, look into joining the AppleSeed testing program. You can read more about that at Rich Trouton’s blog. There will be differences in how often you get releases and perhaps in the kind of release notes you receive, but it at least gets you access to the beta software.

The next step you need to take is to provide Apple with feedback. In fact, Apple lets you provide feedback for free by going to bugreporter.apple.com so long as you have an Apple ID. However, you should ideally use Feedback Assistant especially if you’re in the AppleSeed program.

Unfortunately, due to NDA, I cannot publicly post anything here that isn’t already public. However, the point of this post is to bring some awareness on things that have been made public by Apple that will have a MAJOR impact on any IT administrator managing Macs when macOS 10.14 releases.

Quick recap of changes in macOS 10.13

To give a quick recap, with macOS 10.13, Apple introduced the concept of User Approved MDM (UAMDM). The idea behind this is that devices that have UAMDM can then have their MDM server send out Configuration Profiles that mange specific settings that can only be managed if the device is UAMDM. This can happen one of two ways: 1) the user automatically installs an MDM profile and then approves it, or 2) the device is configured through the Device Enrollment Program.

Apple first started by restricting kernel extensions. Some of those changes during the 10.13 beta were pushed back until better management could be added to the public release. That management feature was the introduction of the User Approved Kernel Extension Loading. You can read more about that at Rich Trouton’s blog. If you notice a trend, Apple has been releasing more and more restrictions with each release of macOS in the name of security. UAMDM is here to stay and more MDM features will probably require it.

Upcoming changes in macOS 10.14

With macOS 10.14, Apple is introducing even more restrictions to what applications can do. I strongly recommend you watch the WWDC full video. The idea of user consent for certain actions taking place by apps or scripts make sense from a security standpoint. This has even bigger implications for IT administrators because often we rely on management tools that may access certain paths that may now require user consent. That’s what the beta is for, right? We can test these new features and the management tools that go with it and provide Apple with valuable feedback.

Unfortunately, although Apple announced these changes to macOS 10.14 on June 5, 2018, the MDM documentation was released August 13, 2018, exactly 69 days later. The relevant change that you will be looking for is Privacy Preferences Policy Control Payload (which according to the revision history was added to that PDF on August 6th, but that’s just not true). That means IT administrators have about 5-6 weeks until late September to test this out. This is absolutely very short notice on Apple’s part to put it mildly. Even more importantly, MDM vendors have 5-6 weeks for Apple to add this new payload (among other new MDM-related changes they’ve made). That means that in order to test this, you need to 1) manually create a Configuration Profile and upload it to your 2) MDM server to push out to your clients which will need 3) UAMDM.

How do I know if I’m impacted?

If you have no idea whether this will impact you, then I recommend the following: get access to macOS 10.14 beta with one of the methods discussed earlier. Run through an installation of macOS 10.14 on a computer and go through your provisioning process for Macs. Run all your tools and scripts that you normally use. Take note of the errors that you start getting and provide that feedback to Apple.

Just to give you an example, here is one discussion on the Apple developer forums on how these changes are effecting IT administrators already.

What do I need to do?

It’s important to provide that feedback to Apple because as it stands they are going to absolutely release these new security and management features in 10.14 as announced without providing sufficient time to test and have IT administrators give them feedback on what works and what doesn’t.

Here is a good example of feedback provided by a fellow Mac administrator on Slack:

macOS 10.14 – AppleSeed for IT
 – Problem Report

 

Basic Information
Please provide a descriptive title for your feedback:
Please delay the release of the new TCC security settings to the Sprint Release

 

Which area are you seeing an issue with?
Client Management

 

What type of issue are you reporting?
Suggestion

 

Details

 

Description
Please describe the issue and what steps we can take to reproduce it:

 

Yesterday Apple released Mojave beta 7, and also “silently” updated the MDM documentation to finally describe how to manage these new policies.

 

This is problematic for a few reasons.

 

1. We can only submit regressions/enhancements now, which means there is a high likelihood that they will not be fixed until after the GM release

 

2. Given Apple’s track record of releases in the past few years, this gives us less than 5 weeks to adequately test the impact this will have to our environment, our internal tools and any developer applications/tools we could deploy

 

3. This also gives MDM vendors less than 5 weeks to offer support for this

 

4. There is no documentation on what Apple deems protected vs unprotected (See Feedback 4813904)

 

This is very similar to what happened last year with High Sierra, User-Approved MDM and User-Approved Secure Kernel Extensions.

 

This documentation should have been available immediately following the session “Your Apps and the Future of macOS Security” – https://developer.apple.com/videos/play/wwdc2018/702/ – This session was live streamed on June 5th, 2018 and the MDM documentation was released August 13th, exactly 69 days later.

 

In which build did you encounter this bug?

 

macOS 10.14 – Beta 7 (18A365a)

 

As an aside, you should contact your MDM vendor to ensure they are aware of this important Configuration Profile payload feature that will be necessary for macOS 10.14. You can link them to the Configuration Profile Reference.

A special note for Jamf Pro customers: please sign your Configuration Profile when you upload it to Jamf Pro to avoid Jamf Pro messing with it. Also, if you’re a Jamf Pro customer, I’ve already made a feature request for them to support this new payload. I’m not entirely sure whether they will be able to release it by macOS 10.14’s release date, but at least it’s on their radar and marked as planned. Another thing to keep in mind: extension attributes are scripts in Jamf Pro that are meant to often collect data. Make sure these scripts/Extension Attributes are running properly in 10.14.

What else can I do?

You can participate in the Apple Developer Forums. There are also a few Mac administrators on Slack speaking about the changes which you can join for free: http://macadmins.org in #tcc channel. (Did you know TCC stands for Transparency, Consent, Control?) You can encourage other Mac administrators to spread the word and file feedback and bug reports with Apple so that they can understand how poorly timed their documentation on this has been for testing. Blog about this. Reach out to your Apple account reps. Basically, you need to do whatever you can so that Apple is aware that these changes are going to be absolutely showstopping for a lot of organizations that have been given little time to test these new features.

What’s the ideal outcome?

In a perfect world, Apple would have released these features and documentation in the very first beta. However, given how late it is now in the beta testing cycle, the next best thing that Apple can do is 1) fix whatever outstanding issues may exist with these new management features, 2) provide a complete whitelist for all UAMDM devices until it can be properly implemented, and 3) properly document what specific areas of the operating system will now require user consent. They’ve done this before with UAKEL where all Kernel Extensions were completely whitelisted in High Sierra until macOS 10.13.4 at which point you could whitelist specific Kernel Extensions.

IT administrators and MDM vendors simply need a little bit more time to these these out. In essence, give us at least those 69 days that you stole from our testing back. I’m not a fan of a moving target on major features in the middle of a major OS release, but at least this would provide organizations time to thoroughly test these features out. This is just my opinion of course. Comments welcomed below. You are more than welcome to provide a differing opinion on this as long as you provide feedback to Apple!

And hopefully for whatever Apple is planning in macOS 10.15, they will plan accordingly and release those management features in the very first beta for IT administrators and MDM vendors to test.

Disable iCloud Desktop and Documents Sync

Apple is still currently testing 10.12.4 Beta 7 as of the time of this post, but they apparently have introduced a new payload preference that can be managed through a configuration profile. You can read more about this preference key publicly through their documentation (no login required). The new preference key is allowCloudDesktopAndDocuments which accepts a boolean value. If set to false, disallows macOS cloud desktop and document services. Defaults to true. Available only in macOS 10.12.4 and later. For enterprises, this is a rather important preference that should have probably been released when 10.12 first released, but better late than never.

Continue reading Disable iCloud Desktop and Documents Sync