Store-to-leak forwarding also reads pre-loaded data by exploiting the efficient way in which computer processors function. “The computer assumes that I want to use the data which I have just written to the processor again right away. So it keeps it in the buffer for faster access,” explains Gruss. This functionality can also be used to determine the architecture of the computer processor and find the exact location where the operating system is running. “If I know exactly where the processor is running the operating system, then I can launch targeted attacks against flaws in the operating system.”
A workflow for more user intuitive macOS updates. Allowing the user to defer updates to a more convenient time after updates become available, while allowing for greater assurance that security updates are being applied to IT.
As we get ready to approve kernel extension for our Apple fleet, here is some background on how things evolved.
Kernel extension (KEXT) – MacOS kernel combines the features of a microkernel (load the minimum to run the OS separately from other services) and a monolithic kernel (everything needed for the OS, drivers and filesystem are in the kernel space like BSD). In MacOS, kernel extensions are used by different applications to grant low level access to the hardware. For example, some software, like Antivirus, require access to the computer hard disk and memory to function correctly.
Depending on the skill level of the developers writing these apps, some kernel extensions might be poorly written. There are some apps that don’t even remove the kernel extension when you uninstall them. Others can cause random crashes to your OS or slow down your machine. Apple wants to give the user control over the applications that are installing kernel extension on our Macs and gives the MacAdmins a way to approve them for your fleet.
Let’s take a look how the security of Mac OS evolved over time.
OS X 10.8 (Mountain Lion, and earlier, 2012) – Digitally signed kexts are not allowed and wont load.
OS X 10.9 (Mavericks, 2013) – Signed kexts will load but not enforced.
OS X 10.10 (Yosemite, 2014) – Signed kexts enforcement. Your kext will not be loaded if it’s not digitally signed.
OS X 10.11 (El Capitan, 2015) – SIP is now taking care of the code signing verification.
OS X 10.13 (High Sierra, 2017) – Secure Kernel Extension Loading (SKEL) is managed now by System Integrity Protection (SIP).
User Approved Kernel Extension Loading (UAKEL) was introduced to give users control over which kernel extension are allowed to load on their Mac during the software installation.
User Approved MDM (UAMDM) – As an admin, you want to manage certain security-sensitive settings on a Mac to keep security tight. If you use DEP, you are good to go since the device already belongs to your account. The other option is to manually “Approve” additional management privileges from the users computer.
The idea behind this is that some actions have to be approved by the user of the Mac so that a sneaky MacAdmin won’t be able to run items on a user’s personal device without their knowledge. Any user, not only computer administrators, can approve a kernel extension unless restricted by the MDM.
You don’t have to enroll to an MDM to approve kernel extensions manually and can approve them when notified during installation, via the security menu in system preferences.
A few important notes
When you are upgrading to macOS High Sierra or later, all third-party KEXTs that were already installed at the time of upgrading are automatically approved and don’t require any user action.
Automation or attempting to enroll a device remotely via screen sharing will not result in a “User Approved enrollment”. You have to connect a mouse to the device and click a physical button. You can connect via Apple Remote Desktop app and use a USB mouse to click a button if there is no screen connected to the device.
When approving KEXTs manually and if not approved during installation, the approval “Allow” button is only available for 30 minutes after booting, will reappear after a restart in the “security and privacy” -> “general” tab. However, you will no longer see that pop-ups asking you to approve the kernel extension
Back to kernel extensions, once a device is “User Approved” you can use the MDM to whitelist the kernel extension you approve in your organization. More on that below.
Let’s get technical
To identify the KEXT, macOS uses Team Identifier to identify the vendor or Bundle Identifier to identify the specific application installing the KEXT. Here is a community maintained list of known identifiers :
If you want to whitelist the vendor like “Google” you can use their Team ID “EQHXZ8M8AV”. This means that any future KEXTs by Google are automatically approved. If you prefer to whitelist Google File Stream you can use the Bundle ID “com.google.dfsfuse.filesystems.dfsfuse”. However, you must specify the Team ID in both cases
Location of Kernel Extension
Approved and system KEXTs can be found in:
Newly installed 3rd party KEXT are copied to the folder mentioned below and once approved, a copy of the extension is made to the one of the folders above and allowed to load.
Add a separate JAMF account for each member on the team that can only perform enrollments. This way you’ll have an audit trail of enrollments to your MDM and it simplifies monitoring.
This will install a certificate (if its self-signed) and an MDM config profile. Once this is done, you can push the config profile with the approved KEXT Team or Bundle ID payload to the device.
The approved kernel extension payload must be pushed via an APNS transaction from the MDM server to a Mac. A profile with this payload will not work if it is installed via script and/or package.
Use a separate Config profile and apply it to the Mac before deploying the software that installs the KEXT. You can to deploy all of the kernel extension to all company computers.
Give the profile a general name like “Approved Third-Party System Extensions” to avoid questions from users.
Finally the JAMF payload itself
Now let’s create and deploy the KEXT approval payload with the MDM. Create a new configuration profile and define the desired scope. Add the Approved Kernel Extension payload with the relevant details. Here is that community google sheet link again:
HFS is 30 years old, was designed when there were no permission, no hard links, no extended attributes and checksum in mind. Apple added and corrected many times over the years which cause the system to become less efficient and …. kinda crashy. The biggest issue with that is that files on HFS could get corrupted over time and you would lose your precious photos after all those years.
Apple needed a file system for its newer devices like Apple watch and AppleTV
The increasing use of SSD technology. APFS is optimized for flash and solid-state drives and leverages their high seek and access speeds, much faster than spinning drives.
Improving the encryption and making it hog less CPU.
The benefits of APFS
Optimise the space of the HDD used and increase free space by using clones for file copying and using deltas.
Improve the write speed by removing the need for journaling and switch to “write on copy” and by changing the way file are stored and pointed to on the disk. This is efficient on SSD. When you make a copy of a file no blocks are copied and a pointer is added from the new file to the previous file’s data. If you make changes to the original file, APFS created new records in the file system with the changes that you made. This is possible due to the low access time of SSD vs HDD that take time to spin the drive.
64-bit file system that helps with space savings and performance improvements
Snapshots – they are allowed by the “write on copy” that enables you to “copy” a huge chunk of data within seconds
End users can store up to nine quintillion files on a single volume, boom! (only 4 billion today))
Apple also changed the way to decrypt the APFS partition. The Preboot volume has the data needed to boot to the FileVault preboot login screen and to decrypt the volume (Using the T2 chip to verify integrity, more on that in future posts)
With APFS an abstraction level called “containers” was added. Volumes now reside in containers and those volumes can “share the free space” meaning they can change without repartitioning. Yey!
The downside of APFS
Not compatible with HFS+ or NTFS . MacOS 10.12 and before will not be able to access it.
Should not be used on HDDs due to “write on copy” and the “fragmentation” of copied files. HDDs have low seak speed and will be slowed down by this feature
Does not support direct hard link, will be converted to soft links during the conversion (During an upgrade to a new OS)
What can we do with it
Take a snapshot of your Mac APFS container during testing and revert to its original state instead of reinstalling. Read this article by the awesome Emily to get some info.
Here are some of the commands:
tmutil - make snapshots on apfs command (old time machine control)
tmutil thinlocalsnapshots / 1000000000 1 - remove older snapshots based on priority
Take a snapshot before a major upgrade or add this to you scripts or Jamf self service before upgrading the OS.
Snapshots are kept locally for up to 24 hours and also erased based upon free disk space. You could create a script or use launchctl (or crontab) to take a snapshot every X amount of time without having the Time Machine drive connected for local
I’m learning to love Jamf every day and this time it’s the simple task of setting the wallpaper for newly installed computers
There is a simple way to setup a Wallpaper with a configuration profile. However, this will force the wallpaper and people will not be able to replace it later. I did not want that functionality.
I found a nice method that I’ll describe here that ended up working for me. One thing to note is that I do not have DEP and the policy runs from the users account that I manually create on the Mac.
The first part is straightforward. I packaged the wallpaper PNG file to be deployed to the users’ document folder with the Jamf composer. I used FEU (Fill existing user home directories) to make sure it goes to the users home folder and does not create one with my username in the path. Then I exported to a dmg file as .pkg files will not work with FEU.
Next, I used this amazing tool called Desktopper on Github. Packaged it and deploy the .pkg in the same policy. With Desktopper you can point it at the PNG file I copied to the users’ Documents folder and set it on the some or all displays as the wallpaper.
I could use the “Files and Processes” section of the policy but then the desktoppr will run as the root user and will not give me the result I want.
The solution I ended up using is called Outset and can be found on Github and…. it is awesome. Outset is a script which automatically processes packages, profiles, and scripts during the boot sequence, user logins, or on demand.
What I need to do is put create a script with the correct permissions, that will run the desktoppr and set the PNG file. That script went to the “login-once” folder of Outset. This way the script will apply the wallpaper after the first login for every user on this Mac. Added it to the scripts in Jamf. This was the last piece of the puzzle.
## Create a script in the outset Run-Once folder
cat <<EOF>> /usr/local/outset/login-once/SetWallpaper.sh
/usr/local/bin/desktoppr main ~/Documents/FBwallpaper.png
## Give the script execute permission
chmod +x /usr/local/outset/login-once/SetWallpaper.sh
As scope, I set up a new smart group that includes all of our user machines that were enrolled in the last day. I do not want this to replace the wallpaper of my CEOs favorite cat or something. So that’s it, guys. Please let me know if you have a better way to get the job done or any questions.
In this article we will go over .plist files, defaults command and some software to work with plist files.
All of the Macs preferences are stored in plist files (property list file). Some settings are not accessible from the GUI of the MacOS or its applications preferences menus. You might also want to configure an application before a user launched it on a new Mac he just got : For example, you might want to set the default home page for a browser, adjust the screen to lock after three and a half minutes or set the VPN configuration.
Every time you make a change to a setting via any menu, those changes are reflected in the relevant plist file by updating an entry and setting a value on that entry in the relevant plist file. It looks like an XML file, but if you try to open it, you will not be able to read it with a text editor as it is a binary file. You need a program to interact with those files. This is where the defaults command comes in.
We can take a look at the many .plist files located at:
Preview plist files
MacOS has a nice feature that allows preview to display the content of a plist file that is readable. Once you select the file you want to view, hit space, and the content will be displayed.
Quick edit plist files
When you are using the defaults command you need to specify if you want to read a plist or update it.
defaults read com.apple.finder
View only the value of AppleShowAllFiles. The result can be TRUE, FALSE, YES or NO.
You might need to convert the plist file into something more human readable. Use the plutil command to convert plist to txt. I use this when I need to take the content of a plist file and paste its content to JAMF to deploy it. Make a copy of the file you will be converting and…
plutil -convert xml1 com.apple.finder.plist
You can reverse the conversion using:
plutil -convert binary1 com.my.app.plist
Applying what we learned + some useful apps.
You would like to change the homepage for all your Macs in the Chrome browser to your company portal.
The first thing to decide on is this a user or a computer policy and how will you be deploying it
Now you need to know where is the file that you need to edit. This can be done by Googling the file to update and then using the defaults command.
You can also look at the file system changes when you are making that change on a virtual MacOS. I love an app called http://fsmonitor.com/. It gives you this nice tree look of the live updates to the OS.
Another super great tool is Pref Setter. It will show you a list of all the plist found on the Mac and gives you an option to update from inside the app. I would not recommend using it to update, it’s quite old, but it is great to get a general view.
PlistEdit Pro is my tool of choice for editing. It gives a great visualization and simplifies editing. There is also a more affordable alternative here.
There is also a tool that is provided by Apple called plistbuddy.. I have not used it yet but heard it mentioned several times on the MacAdmins podcast.
Adding default settings to packages
Let’s say that that you are building a package with JAMF composer and you need to add some default setting for that app. Once you add the app and use a post-install script to run the defaults command with the values you want. Make sure to build a .pkg file though if you want it to work correctly.
Well, that’s it for now guys. While doing some research for this article, I found a book by Armin Briegel (https://scriptingosx.com) . His book Property Lists, Preferences and Profiles for Apple Administrators is only available with a US Apple ID. Perhaps future books will be as he mentioned on his blog post.