PSU MacAdmins 2018 Links

Here are some links from my presentation at the 2018 MacAdmins Conference at Penn State, “Imaging is Dead: Now What?”

Der Flounder, “Imaging will be dead soonish”: https://derflounder.wordpress.com/2017/01/10/imaging-will-be-dead-soon-ish/

AutoDMG: https://github.com/MagerValp/AutoDMG

Imagr: https://github.com/grahamgilbert/imagr

DeployStudio: http://www.deploystudio.com

Apple, “Upgrade macOS on a Mac at your institution”: https://support.apple.com/en-us/HT208020

Apple, “APFS and Imaging”: https://help.apple.com/deployment/macos/#/apd545ec8b69

Apple, “Restoring an iMac Pro with Configurator”: https://help.apple.com/configurator/mac/2.6/index.html?localePath=en.lproj#/apdebea5be51

Apple, “How to create a bootable installer for macOS”: https://support.apple.com/en-us/HT201372

createbootvolfromautonbi.py: https://github.com/munki/macadmin-scripts/blob/master/createbootvolfromautonbi.py

Bootstrappr: https://github.com/munki/bootstrappr

Erik Gomez, Custom DEP series: http://blog.eriknicolasgomez.com/2017/03/08/Custom-DEP-Part-1-An-Introduction/
http://blog.eriknicolasgomez.com/2017/03/08/Custom-DEP-Part-2-Creating-a-custom-package-and-deploying-Munki/
http://blog.eriknicolasgomez.com/2017/03/08/Custom-DEP-Part-3-Best-Practices/
http://blog.eriknicolasgomez.com/2017/03/08/Custom-DEP-Part-4-The-Future/
http://blog.eriknicolasgomez.com/2017/04/05/Custom-DEP-Part-5-Dynamic-InstallApplication/
http://blog.eriknicolasgomez.com/2017/04/27/Custom-DEP-Part-6-Vendor-Announcement-and-Presentation/
http://blog.eriknicolasgomez.com/2017/07/27/Custom-DEP-Part-7-Getting-started-with-AirWatch-9.1.3/

Victor Vranchan, “Munkiing around with DEP”: https://groob.io/posts/dep-micromdm-munki/

Armin Briegel, “macOS Installation for Apple Administrators”: https://scriptingosx.com/macos-installation-for-apple-administrators/

installinstallmacos.py: https://github.com/munki/macadmin-scripts/blob/master/installinstallmacos.py

Unwelcome Apple surprise

This morning while reviewing new updates on my reposado server I saw this new update:

091-76348   macOS High Sierra                           2018-04-10 []

I didn’t think much of it; various “Install macOS High Sierra” updates have appeared in the softwareupdate catalogs since early in the High Sierra beta cycle: the App Store, when installing the “Install macOS High Sierra” application, downloads resources from these catalogs. (See https://managingosx.wordpress.com/2017/09/26/some-stuff-about-install-macos-high-sierra-app/ for more info).

But then I saw this cry for help on the munki-discuss list: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/munki-discuss/I9nA-340mO4/KVQTJMEGCgAJ

Apologies if this has been asked and answered already, but we’re in a desperate time crunch. This morning, on the second day of standardized testing for our district, High Sierra is appearing as a “regular update” instead of an App Store option, so naturally MSC offers it:

It appeared that “macOS High Sierra” was being offered as an Apple software update (which Munki was then offering to install).

Early notes on deploying images to iMac Pro

Overview

Here are some early notes on making and restoring a High Sierra deployment image to an iMac Pro.

“Wait, I thought imaging was dead! Especially imaging the iMac Pro with Secure Boot!” you may be thinking. My reply: “We’ll see, won’t we?” It’s early days here: we’re experimenting. Our experiments might lead to dead ends, or they might lead to useful results.

MacTech Conference 2016

I’ll be speaking at MacTech Conference 2016, November 16-18 in Los Angeles: http://conference.mactech.com

You can save $600 on the registration costs if you register by May 31: http://conference.mactech.com/pricing/

Packaging Lab at MacTech Conference 2015

If you are planning on participating in the Packaging Lab this week at the MacTech Conference, you may want to download some materials in advance when you aren’t competing with all the other people for limited conference Wi-Fi bandwidth. Note — don’t install these items — just download their installers and keep them handy for the lab.

ExifTool pkg:
http://www.sno.phy.queensu.ca/~phil/exiftool/ExifTool-10.03.dmg

Adobe Reader 11 pkg:
http://ardownload.adobe.com/pub/adobe/reader/mac/11.x/11.0.10/en_US/AdbeRdr11010_en_US.dmg

Google Earth pkg:
http://dl.google.com/earth/client/advanced/current/GoogleEarthMacNoUpdate-Intel.dmg

Firefox dmg:
http://ftp.mozilla.org/pub/firefox/releases/latest/mac/en-US/Firefox%2042.0.dmg

Google Chrome dmg:
https://dl.google.com/chrome/mac/stable/GGRO/googlechrome.dmg

Some optional things:

Packages:
http://s.sudre.free.fr/Software/files/Packages.dmg

Suspicious Package:
http://www.mothersruin.com/software/SuspiciousPackage/download.html

Pacifist:
https://www.charlessoft.com

MacSysAdmin 2014

I’m excited to be presenting once again at MacSysAdmin 2014 in Gothenburg, Sweden!

https://macsysadmin.se/2014/Home.html

The current plan is that I will talk about what’s new in Munki (so I’d better finish a lot of the stuff I’m working on before then!) and, together with Tim Sutton, a detailed talk on AutoPkg.

MacSysAdmin is September 16th through September 19th, 2014 – hope to see you there!

XProtect Updater Redux

In the past 24 hours, Apple has released an update to the XProtect malware definitions. If your Macs have received the latest XProtect definitions, Adobe Flash Player will be blocked unless it is the version current as of yesterday (11.5.502.149).

If you have already updated your clients to that version of the Flash Player, good for you!

If you don’t want to be surprised by this sort of thing and have to scramble to address it, might I point you here?

Still more on the XProtect Updater

Mike Boylan writes in a reply to my previous post:

…I have to respectfully disagree that disabling the auto-update mechanism for Xprotect should be done in organizations with managed machines. Do you disable the automatic update mechanism for your anti-virus software? Do you manually test every definition update and push each one out through Munki? I’d assume not. Xprotect (clearly) isn’t serving the same type of updates as Apple software update. It’s a malware prevention/blocking (and in some cases, removal) system. I won’t argue that Xprotect’s disabling of Java plugins will almost certainly have a larger impact across organizations than say something like a Sophos definition update, but nonetheless, the intent is still to protect systems. Xprotect and anti-virus software together are meant to serve complimentary roles. These Java plugins are being disabled because serious known exploits are being used in the wild. For a company that cannot function without version xyx of the Java plugin, does it make sense to make changes so that it can continue to operate effectively? Sure. But I doubt most organizations rely that heavily on a single plugin. Also, how many different types of updaters should we as admins be responsible for managing? There are already too many. For most admins, I don’t think it’d be a responsible decision to add Xprotect to the list.

Mike:

If Xprotect’s disabling of web plugins has not caused your organization any issues, or you are willing to react to any issues such disabling might occur in the future, it may well make sense to leave things as they are for your organization.

In my organization, the Java 6 web plugin is required to perform vital, daily business functions. When it doesn’t work, business functions are seriously impacted.

My argument might be subtle.

Apple is acting as systems administrator for machines by updating the XProtect plists. As long as you are content to let Apple make those changes, and won’t complain if Apple makes a change that breaks things for you, by all means, leave the XProtect updater mechanism alone.

If, on the other hand, _you_ are taking responsibility for managing your machines, making sure they are functional for your organization, and keeping them safe from malware, you’ll want to disable _Apple’s_ update of the XProtect malware definitions, and take over updating them yourself.

If you do not want to be surprised that one morning Java or Flash or some other plugin has been disabled on all the Macs you manage, you cannot let Apple update these definitions without your review. You must take responsibility for reviewing and implementing Apple’s changes, or a modification thereof.

Is this more work? Yes. Does it add risk to your organization? Probably. All security is a trade-off between functionality and protection. Malware protection that prevents my users from doing their work is not an acceptable trade-off. Apple has made one decision about the trade-offs, one that protects a great number of Mac users while negatively affecting a very small number of them. That is not the correct decision for my organization.

The only way I can ensure the correct decisions are made for my organization is to not leave the decision making process solely to Apple, but to instead review Apple’s changes and alter them if needed for the benefit of my organization.

Each organization needs to weigh this decision for themselves.

More thoughts on XProtect Updater

I’ve been thinking more about Apple’s Xprotect Updater mechanism in light of the recent updates that have disabled Java web plugins. See yesterday’s post, for example.

In many enterprise environments, admins choose to run their own Software Update server to provide Apple updates. This is done for several reasons. One is to save bandwidth — it’s more efficient for a single machine to download available Apple updates over your Internet connection, then have all the other machines get those updates over the local LAN.

But another reason is to be able to control which updates are offered to your managed computers. Apple may offer an update that causes issues in your organization. For example, we did not deploy the “Java for OS X 2012-006” update in our environment because it disabled the Java 6 Web Plugin, which we needed.

Yesterday’s Xprotect update essentially did the same thing, this time over a wider range of machines. I quickly put together a workaround, but one of the things the workaround does is to turn off the automatic updates of the XProtect data.

After thinking more about the ramifications of this, I think that this is exactly what most enterprise sites should do. They should treat this update mechanism like all other update mechanisms. I think you should turn this off on most or all of your managed machines.

“But wait,” you are thinking. “Isn’t this risky? Apple is trying to protect users from malware.” If you only turned off the update mechanism on all your machines and did nothing else, you are adding risk. But what you should do is something similar to what an admin that vets Apple Software Updates (or third-party application updates) does before releasing them.

You should enable the update mechanism on an admin machine. When there are new XProtect.meta.plist and/or XProtect.plist files, you should test to see that they don’t cause any issues in your organization, modifying them if needed. You can then use your favorite software deployment system (I like Munki) to distribute these files to your managed machines.

In this way, your managed machines can still get the benefit of updates to Apple’s malware protection mechanism without risking that a component vital to your organization will be blocked without warning.

Disabled Java Plugins, XProtect Updater

Today Apple updated the XProtect.meta.plist file, which, among other things, causes XProtect to disable Java Plugins that don’t meet a minimum version.

The net effect was to disable the Java 6 plugin on all browsers, as well as Java 7 plugins older than 1.7.11.22.

If you need to continue to use the Java 6 plugin in your organization, you can revert the changes and disable the mechanism that updates the XProtect.meta.plist by installing this package:

https://dl.dropbox.com/u/8119814/DisableXProtectUpdater.pkg.zip

This is a payload-free package that runs this script as a postflight:

#!/bin/sh

# don't check JavaWebComponentVersionMinimum
XPROTECT_META_PLIST="$3/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist"
/usr/libexec/PlistBuddy -c "Delete :JavaWebComponentVersionMinimum" "$XPROTECT_META_PLIST"

# disable the xprotectupdater job
LAUNCHD_JOB_PLIST="$3/System/Library/LaunchDaemons/com.apple.xprotectupdater.plist"
/bin/launchctl unload -w "$LAUNCHD_JOB_PLIST"

I won’t tell you this is a smart thing to install; there are many reasons to leave things as they are. Apple disabled these plugins to protect from known exploits. By re-enabling them, you are opening up your managed machines to these exploits.

But if your org needs the Java 6 Web Plugin, this should get you running again. You should re-enable the XProtect updater as soon as you are able, though:

sudo /bin/launchctl load -w /System/Library/LaunchDaemons/com.apple.xprotectupdater.plist

NOTE: if you need to re-enable an older version of the Oracle Java 1.7 Plugin, you’ll need to edit the postflight script and add something like:

/usr/libexec/PlistBuddy -c "Set :PlugInBlacklist:10:com.oracle.java.JavaAppletPlugin:MinimumPlugInBundleVersion 1.7.10.19" "$XPROTECT_META_PLIST"

(Sadly, WordPress changes a colon followed by a P into a emoticon, even in pre-formatted text. Not helping…)

This sets the MinimumPlugInBundleVersion for the Oracle Java Web Plugin back to the value it was with the 10 Jan 2013 version of the XProtect.meta.plist. Again, if you do this, you are choosing to expose your machines to a known Java Web Plugin exploit. Do so at your own risk.

(Update 01 Feb 21013)
If you need to run the Oracle Java 1.7 Plugin (or are already running it and it’s been disabled) the best fix is to update the Java install. As of this writing, Java 7 Release 13 for OS X is available here. This installs a web plugin with BundleVersion 1.7.13.20.

(Update 02 Feb 2103)
Apple has released a Java 6 update for Snow Leopard. Installing this update will restore Java 6 web plugin functionality under Mac OS 10.6. This won’t help if you need to use the Java 6 web plugin under OS X 10.7 or later.