Archive
Slides from the “MDM: From “Nice to Have” To Necessity” session at MacDeployment 2019
For those who wanted a copy of my MDM talk at the MacDeployment 2019 conference, here are links to the slides in PDF and Keynote format.
PDF – https://tinyurl.com/MacDeploy2019PDF
Keynote – https://tinyurl.com/MacDeploy2019Keynote
New TLS security requirements for iOS 13 and macOS Catalina 10.15
As part of the information published at WWDC 2019 by Apple, the following KBase article has been released:
Requirements for trusted certificates in iOS 13 and macOS 10.15: https://support.apple.com/HT210176
This KBase article describes how Apple is implementing new security requirements for TLS server certificates. These certificates are used by servers to encrypt communication between Apple devices and those servers, to make sure that all communication between the servers and those devices is protected.
- Certificate key sizes must be 2048-bit or greater
- SHA-2 must be used for the certificate signing
- DNS hostname of the server must be listed in a Subject Alternative Name (SAN) certificate extension in addition to being listed in the Common Name field of the certificate.
Also, all TLS certificates issued after July 1, 2019 must meet these additional requirements:
- Must be valid for 825 days (27 months) or less
- Must contain the following Object Identifier in the ExtendedKeyUsage extension: id-kp-serverAuth
What happens if you use iOS 13 or macOS Catalina to try to connect to servers with TLS certificates which don’t meet these standards? The connection will fail because the OS will reject the certificate as being invalid. This may result in a web browser not connecting, an app crashing or some other undesired behavior.
As part of testing iOS 13 and macOS 10.15 ahead of their release dates, I strongly recommend testing the various services used at your workplace to make sure that the TLS certificates used by the services of your company, school or institution are able to pass these requirements. Otherwise, you may find some unfortunate surprises on Release Day this fall.
Using bootstrappr to build testing VMs with VMware Fusion
As part of my preparation for next week’s WWDC conference, I’ve been working on ways to build virtual machines using VMware Fusion for testing. In previous years, I have used NetBoot-based solutions to help me with this process. With NetBoot going away though, I’ve started using bootstrappr as my replacement deployment tool.
Bootstrappr is designed to install packages and scripts, but in my case I’m having it install only one package: a firstboot package created by First Boot Package Install Generator.app. The firstboot package in turn installs a set of installer packages to configure the VM and install the software I want. For more details, please see below the jump.
Using AutoPkg 1.1’s recipe template creation option
As part of the release of AutoPkg 1.1, a new-recipe feature was added to help with recipe creation.
It will create a generic recipe file with the following keys added:
- Description
- Identifier
- Input
- MinimumVersion (by default, MinimumVersion will be set for AutoPkg 1.0)
- Process
Under the Process keys, there are additional keys created by default:
- Arguments
- Processor
As an example, here’s the recipe file which is created when the following command is run:
autopkg new-recipe ~/Desktop/MyGreatApplication.download.recipe
For more details, please see below the jump.
macOS, hyperthreading and Microarchitectural Data Sampling vulnerabilities
In 2018, vulnerabilities were publicly disclosed in computer processor architecture which affected the vast majority of desktops, laptops, mobile devices and servers. These vulnerabilities are referred to as Meltdown and Spectre. There is a lot of information available online about these vulnerabilities, but the cartoon below provides a decent summary of the issue:
On May 14th, 2019, additional Spectre vulnerabilities were disclosed using the name Microarchitectural Data Sampling (MDS). These vulnerabilities apply to desktop and laptop computers which use Intel processors. These processors are used by all modern Macs, but not by iOS or Apple Watch devices. These devices do not use Intel processors and instead use Apple’s own processors. For an excellent round-up of information on this developing issue, please see @zoocoup‘s post available via the link below:
https://mrmacintosh.com/mds-vulnerabilities-summary-for-macadmins-by-jason-broccardo
How to remediate this problem? For the details, please see below the jump.
Creating, managing and using Apple File System snapshots for startup drive backups
Starting with macOS High Sierra, Time Machine on Apple File System-formatted (APFS) startup drives gained the ability to create APFS snapshots. These snapshots capture the state of the startup volume at a particular point in time and can be used by Time Machine to restore files, folders or the whole startup volume. These snapshots are stored on the startup volume, but are not the same as the previous local backups that Time Machine used on Hierarchical File System Plus (HFS+) formatted drives.
On HFS+ formatted drives, Time Machine local backups are stored in an invisible directory named .MobileBackups on the root level of the startup drive.
This .MobileBackups directory is mountable as /Volumes/MobileBackups and you can access the backed-up files stored inside by navigating via the command line or Finder window.
On APFS formatted drives, the /.MobileBackups directory and /Volumes/MobileBackups are no longer available. Instead, Time Machine is now using APFS snapshots to store a read-only copy of the state of your Mac’s startup drive at the time when that snapshot was taken. These snapshots are invisible to the file system, so unlike HFS+, there isn’t a directory or file location which you can access to get access to the snapshot-stored backups.
Snapshots include all files and directories stored on the startup drive at the time that the individual snapshot was made. When available, these snapshots can be used to restore the following:
- Individual files
- Individual directories
- Multiple files at once
- Multiple directories at once
- All files and directories at once
If the startup drive was encrypted at the time the snapshot was made, the snapshot will itself be encrypted. This allows the restoration of an encrypted startup drive without needing to decrypt or re-encrypt the relevant startup drive. For more details, please see below the jump.
Notarizing Automator applications
Apple recently updated their notarization documentation to include this note:
Beginning in macOS 10.14.5, all new or updated kernel extensions and all software from developers new to distributing with Developer ID must be notarized in order to run. In a future version of macOS, notarization will be required by default for all software.
The part about “notarization will be required by default for all software” made me think, because there are a few apps that I’ve written over the years that are still useful (at least to me). All of them were built using Automator, which meant that the usual Xcode-based ways of notarizing applications wasn’t going to work for me.
With assistance by folks in the MacAdmins Slack though, I was able to develop a process that allowed me to do the following:
- Codesign an Automator application
- Upload the application to Apple for notarization
- Attach the notarization to the application
- Verify that the notarization was attached and valid.
The documentation linked below was also very helpful in figuring out how to notarize using command line tools:
- https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution/customizing_the_notarization_workflow
- https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution
For more details, please see below the jump.
Recent Comments