7 ms·

Because, like ChromeOS/CoreOS, modern macOS now does image-based updates. A macOS update isn’t “whatever was previously on your OS volume, plus arbitrary patch

by derefr 6y ago

Because, like ChromeOS/CoreOS, modern macOS now does image-based updates. A macOS update isn’t “whatever was previously on your OS volume, plus arbitrary patch X”; rather it’s “a new, fresh OS disk image, written to a separate APFS volume, with a fixed SHA, with update transfer-size optimized by composing said image partially from files in your current OS, but only in such a way that the volume will still hash the same in the end.” (In many ways, macOS’s update system now reuses the logic from iOS’s IPSW firmware-update system. You can even now download macOS updates from Apple as IPSW files, and then use Apple Configurator to push them to macOS devices.) Unlike ChromeOS/CoreOS, after the first-round SHA verification of the volume, macOS will then patch the new OS-base-image volume with certain files from your current OS-base-image volume, if 1. they’re distinct from the ones it expected to be there, and 2. they appear on a whitelist of known-safe files. If any of this patching happens, the OS volume’s metadata tree will then be re-hashed, and the new hash will be blessed by the volume-signing utility. (If you’ve seen a “Recovered Files” directory on your desktop after an update, and it’s contained a “foo.system_default” file, that’s a copy of the file that macOS would have composed into the OS volume if it hadn’t found your known-safe customized file to use instead. /etc/shells is a usual trigger.) Some preference files in /System/Library are known-safe; but others aren’t. It’s a whitelist, and it’s a conservative one. Preference files in /Library live in the user volume, not the OS volume, and so will never be wiped. This is why most of the “trivial” preferences stick around. Note that by “known-safe” here, I don’t mean “can’t be customized to malicious ends.” This isn’t a security thing. It’s an ABI stability thing. These files are safe in that they’re known to have the same ABI format between OS versions, and so keeping a customized version of them around won’t confuse newer versions of system daemons. It’s about the same as if Linux had a set of known-safe DKMS modules that use interfaces that the kernel intentionally doesn’t change between releases, such that the kernel module files composed from those DKMS modules could be reused by the new kernel without requiring decompilation, rather than being tossed out at every single kernel update.

samstave 6y ago
Why cant Apple use their TimeMachine tech to take a snapshot of the prefs on the existing, then do their image based update, then have it automatically apply the prefs from the timemachine mod-integration? The richest company in the world can't think different?
- derefr 6y ago
  They know exactly what files were customized in the previous OS-base-image. There’s a reason the whitelist is a whitelist, rather than a blacklist. Just guessing here, but it’s probably something to do with “iteration speed” vs. QA SLAs made to large enterprise customers like IBM. In my hypothetical, there’s a set of preferences overrides Apple have been forced by contract to guarantee they’ll validate during their QA process, and then allow the OS to retain between updates. For any other file not forced by contract, they don’t bother with that QA process (“takes too long!”), and so default-distrust the ABI-stability of the file, and so don’t let the OS retain it between updates.
- deleted 6y ago
  [deleted]
- Demigod33 6y ago
  What if one file was written by a malicious program?
  - azinman2 6y ago
    Ya I think saying it’s not for security is making a lot of assumptions.
  - samstave 6y ago
    You know =what would be cool: If all apps had to register their pref config files into a single dir and that would be tracked and snapshotted - and then you could just have ALL apps look to the same dir for where their configs come from and you could have a single repo for ALL apps on your or ANY system - and then you could walk up to a terminal and plug in your "license key" which said what apps you had access to and what ones you had configs for and you could just run that app with all your input and prefs and mappings etc... I actually wrote a white paper on just this in ~2003 or so - and met with several engineers from google and they said it was impossible. The idea being that you only carried around with you your profile, and you could just come to a dumb terminal, plug in your key, three factor auth - and the terminal would give you access to the apps and resources they had... (I should write ((again)) a short story on this)
jeffbee 6y ago
The thing that doesn't make sense here is that macOS discards randomly your settings, but it is also the only OS I use that regularly gets in a fucked up state where settings have to be nuked. I mean, here we are in year 37 of the mac and people are still zapping their PRAMs. The only improvement is you don't have to physically pull out the battery.
- lispm 6y ago
  In year 37 you can't manually zap the 'PRAM' on Apple Silicon Macs.
  - jeffbee 6y ago
    True, but I guess 95% of mac users are still on Intel macs, are still being told by "genius" bar frontline support to reset the SMC / zap PRAM for any kind of issue, and this usually works, too. Jury is still out on whether the M1 auto-zapping architecture is better, or will just be more prone to being permanently messed up.
    - easton 6y ago
      Well, the fact that nobody ever has to zap PRAM on an iOS device means that they’ve probably fixed that (or, since you can’t zap PRAM anymore, people just restore the device instead...)
- wizzwizz4 6y ago
  > but it is also the only OS I use that regularly gets in a fucked up state where settings have to be nuked. Windows gets into this state fairly quickly, too, but the failures are less dramatic so we just live with it. At least with Debian, it only happens when I deliberately change stuff! Though the `xorg-server-video-intel` driver breaks features of post-2007 Intel cards, and it's installed by default, so… perhaps it isn't the perfect OS either.
- chipotle_coyote 6y ago
  Purely anecdotal, of course, but: - If macOS is the only OS that you use regularly that gets in a fucked up state, then either you're not using Windows or it's gotten a lot better in the last few years. :) (I mean, it undeniably has gotten better, but I have Windows-using acquaintances who still kvetch about this issue pretty regularly.) - I've been using Macs since 1999 and I don't think I've had to reset the PRAM to fix a problem since my Titanium MacBook Pro circa 2007. I've had to nuke other settings on occasion, but still generally have markedly fewer problems than I did in my Windows-using days. (Which were more recent than 1999, but still not that recent, so back to the "I'm sure it's better now" disclaimer.) But, Apple definitely needs to have a better mechanism for managing config file updates than "yeah, we've put a few old config files in subfolders of this 'RecoveredFiles' folder, maybe they're useful, maybe they're not, good luck."
curt15 6y ago
>Unlike ChromeOS/CoreOS, after the first-round SHA verification of the volume, macOS will then patch the new OS-base-image volume with certain files from your current OS-base-image volume, if 1. they’re distinct from the ones it expected to be there, and 2. they appear on a whitelist of known-safe files. Red Hat CoreOS (and other Linux systems managed with OSTree, such as Fedora Silverblue) now do something similar by merging the current /etc directory with the "upstream" version.
- IgorPartola 6y ago
  Debian based systems use dpkg which has the option of confold and confnew. Difference is that the default is to ask the user what to do and unattended upgrades default to confold.
- loeg 6y ago
  FreeBSD has an analogous mechanism called etcupdate[1]. I think Boot Environments[2] are pretty similar to SilerBlue but I don't know how BEs manage /etc. [1] https://www.freebsd.org/cgi/man.cgi?query=etcupdate https://www.freebsd.org/cgi/man.cgi?query=etcupdate [2] https://mwl.io/archives/2363 https://mwl.io/archives/2363
IgorPartola 6y ago
This is an excellent explanation. One last piece to clarify: there is no way to edit the known-safe list, is there? And/or there is no way to add a script after the update process that copies files like this, correct?
- derefr 6y ago
  The list itself definitely lives in the OS base-image, so there’s a bit of a catch-22 there. (Imagine if it didn’t! That’d be a bit of an easy loophole for malware authors to exploit!) I haven’t looked into it specifically, but I’m guessing that like many other basically-static system policy property-lists in macOS, the whitelist lives embedded in a Kernel Extension (kext)—probably the kext responsible for update validation. So you’d have to write your own kext to either replace that extension wholesale, or—hopefully—“inject” over just that element of it. Of course, to run your own Kernel Extensions these days, you have to run your Mac in bputil --enable-kexts mode, which is “reduced security” from Apple’s perspective (reduced compared to the security model of iOS, they mean.) On the other hand, the Hackintosh crowd have long agreed that it’s better to just “inject” data into the kernel/OS by either memory-patching the kernel during early boot (Clover), or patching the kernel as it’s being composed into a loadable image (OpenCore), rather than actually modifying anything in /System. (This was before modifying /System was even hard; they just didn’t like making a mess!) I have a strong feeling that that same community that loves their little quality-of-life kext tweaks so very much, is pretty likely to come out with a way to use OpenCore as the boot-loader on real Apple-Silicon Macs, and thus to overlay arbitrary kexts into macOS without actually reducing macOS’s (OS-stage) security policy at all. (Provided you’re okay with the reduction in security of using a third-party bootloader, that is!)
jwiley 6y ago
This is great info I've never seen referenced elsewhere. It would be awesome if you would write a blog post explaining this in more detail!
loeg 6y ago
This is a great answer for "how," but not "why." The file in question is configuration and should not be part of the update image. (Better yet, Apple should surface this functionality somewhere reasonable, like the System Preferences.)

by derefr 6y ago

samstave 6y ago

Why cant Apple use their TimeMachine tech to take a snapshot of the prefs on the existing, then do their image based update, then have it automatically apply the prefs from the timemachine mod-integration? The richest company in the world can't think different?

derefr 6y ago
They know exactly what files were customized in the previous OS-base-image. There’s a reason the whitelist is a whitelist, rather than a blacklist. Just guessing here, but it’s probably something to do with “iteration speed” vs. QA SLAs made to large enterprise customers like IBM. In my hypothetical, there’s a set of preferences overrides Apple have been forced by contract to guarantee they’ll validate during their QA process, and then allow the OS to retain between updates. For any other file not forced by contract, they don’t bother with that QA process (“takes too long!”), and so default-distrust the ABI-stability of the file, and so don’t let the OS retain it between updates.
deleted 6y ago
[deleted]
Demigod33 6y ago
What if one file was written by a malicious program?
- azinman2 6y ago
  Ya I think saying it’s not for security is making a lot of assumptions.
- samstave 6y ago
  You know =what would be cool: If all apps had to register their pref config files into a single dir and that would be tracked and snapshotted - and then you could just have ALL apps look to the same dir for where their configs come from and you could have a single repo for ALL apps on your or ANY system - and then you could walk up to a terminal and plug in your "license key" which said what apps you had access to and what ones you had configs for and you could just run that app with all your input and prefs and mappings etc... I actually wrote a white paper on just this in ~2003 or so - and met with several engineers from google and they said it was impossible. The idea being that you only carried around with you your profile, and you could just come to a dumb terminal, plug in your key, three factor auth - and the terminal would give you access to the apps and resources they had... (I should write ((again)) a short story on this)

jeffbee 6y ago

The thing that doesn't make sense here is that macOS discards randomly your settings, but it is also the only OS I use that regularly gets in a fucked up state where settings have to be nuked. I mean, here we are in year 37 of the mac and people are still zapping their PRAMs. The only improvement is you don't have to physically pull out the battery.

lispm 6y ago
In year 37 you can't manually zap the 'PRAM' on Apple Silicon Macs.
- jeffbee 6y ago
  True, but I guess 95% of mac users are still on Intel macs, are still being told by "genius" bar frontline support to reset the SMC / zap PRAM for any kind of issue, and this usually works, too. Jury is still out on whether the M1 auto-zapping architecture is better, or will just be more prone to being permanently messed up.
  - easton 6y ago
    Well, the fact that nobody ever has to zap PRAM on an iOS device means that they’ve probably fixed that (or, since you can’t zap PRAM anymore, people just restore the device instead...)
wizzwizz4 6y ago
> but it is also the only OS I use that regularly gets in a fucked up state where settings have to be nuked. Windows gets into this state fairly quickly, too, but the failures are less dramatic so we just live with it. At least with Debian, it only happens when I deliberately change stuff! Though the `xorg-server-video-intel` driver breaks features of post-2007 Intel cards, and it's installed by default, so… perhaps it isn't the perfect OS either.
chipotle_coyote 6y ago
Purely anecdotal, of course, but: - If macOS is the only OS that you use regularly that gets in a fucked up state, then either you're not using Windows or it's gotten a lot better in the last few years. :) (I mean, it undeniably has gotten better, but I have Windows-using acquaintances who still kvetch about this issue pretty regularly.) - I've been using Macs since 1999 and I don't think I've had to reset the PRAM to fix a problem since my Titanium MacBook Pro circa 2007. I've had to nuke other settings on occasion, but still generally have markedly fewer problems than I did in my Windows-using days. (Which were more recent than 1999, but still not that recent, so back to the "I'm sure it's better now" disclaimer.) But, Apple definitely needs to have a better mechanism for managing config file updates than "yeah, we've put a few old config files in subfolders of this 'RecoveredFiles' folder, maybe they're useful, maybe they're not, good luck."

curt15 6y ago

>Unlike ChromeOS/CoreOS, after the first-round SHA verification of the volume, macOS will then patch the new OS-base-image volume with certain files from your current OS-base-image volume, if 1. they’re distinct from the ones it expected to be there, and 2. they appear on a whitelist of known-safe files. Red Hat CoreOS (and other Linux systems managed with OSTree, such as Fedora Silverblue) now do something similar by merging the current /etc directory with the "upstream" version.

IgorPartola 6y ago
Debian based systems use dpkg which has the option of confold and confnew. Difference is that the default is to ask the user what to do and unattended upgrades default to confold.
loeg 6y ago
FreeBSD has an analogous mechanism called etcupdate[1]. I think Boot Environments[2] are pretty similar to SilerBlue but I don't know how BEs manage /etc. [1] https://www.freebsd.org/cgi/man.cgi?query=etcupdate https://www.freebsd.org/cgi/man.cgi?query=etcupdate [2] https://mwl.io/archives/2363 https://mwl.io/archives/2363

IgorPartola 6y ago

This is an excellent explanation. One last piece to clarify: there is no way to edit the known-safe list, is there? And/or there is no way to add a script after the update process that copies files like this, correct?

derefr 6y ago
The list itself definitely lives in the OS base-image, so there’s a bit of a catch-22 there. (Imagine if it didn’t! That’d be a bit of an easy loophole for malware authors to exploit!) I haven’t looked into it specifically, but I’m guessing that like many other basically-static system policy property-lists in macOS, the whitelist lives embedded in a Kernel Extension (kext)—probably the kext responsible for update validation. So you’d have to write your own kext to either replace that extension wholesale, or—hopefully—“inject” over just that element of it. Of course, to run your own Kernel Extensions these days, you have to run your Mac in bputil --enable-kexts mode, which is “reduced security” from Apple’s perspective (reduced compared to the security model of iOS, they mean.) On the other hand, the Hackintosh crowd have long agreed that it’s better to just “inject” data into the kernel/OS by either memory-patching the kernel during early boot (Clover), or patching the kernel as it’s being composed into a loadable image (OpenCore), rather than actually modifying anything in /System. (This was before modifying /System was even hard; they just didn’t like making a mess!) I have a strong feeling that that same community that loves their little quality-of-life kext tweaks so very much, is pretty likely to come out with a way to use OpenCore as the boot-loader on real Apple-Silicon Macs, and thus to overlay arbitrary kexts into macOS without actually reducing macOS’s (OS-stage) security policy at all. (Provided you’re okay with the reduction in security of using a third-party bootloader, that is!)

jwiley 6y ago

This is great info I've never seen referenced elsewhere. It would be awesome if you would write a blog post explaining this in more detail!

loeg 6y ago

This is a great answer for "how," but not "why." The file in question is configuration and should not be part of the update image. (Better yet, Apple should surface this functionality somewhere reasonable, like the System Preferences.)