Security Updates leaving mach_kernel visible

In the past, there have been cases where system updates for 10.8.5 (and possibly earlier versions) leave the OS X kernel (at /mach_kernel) visible to users in the Finder. This file has since moved to /System/Library/Kernels/kernel in OS X Yosemite, but previously to Yosemite it is located at /, and included in the package payload for system updates like OS X Combo/Delta and Security Updates.

OS X installers and updaters typically keep this file hidden in the Finder using a tool called SetFile, which is able to set miscellaneous file flags including the “hidden” flag. The Security Update 2015-002 for Mavericks, released on March 9, 2015, does not include any of the postinstall “actions” (miscellaneous scripts and tools executed by a master script) in the installer that were present in the 2015-001 update.

Comparison of SecUpd2015-001 and -002 installer scripts in Pacifist.

Comparison of SecUpd2015-001 and -002 installer scripts in Pacifist.

We have few admin users at my organization, but it has happened at least once that a curious admin user has wondered what this “mach_kernel” file is and moved it to the trash, only to find that their system volume will no longer boot.

Why does Apple continue to ship this bug when they have a knowledge base article on it?

Why does Apple not simply set the hidden flag in the file in the package payload, rather than depend on setting it according to a script? It is possible to set these flags on the file in a payload and not require any scripting to set a hidden attribute on a file.

We can fix this easily by distributing a script to clients that would do something like this:

if [ -e /mach_kernel ]; then
  if ! /bin/ls -lO /mach_kernel | grep hidden > /dev/null; then
    echo "Un-hidden /mach_kernel found, hiding"
    /usr/bin/chflags hidden /mach_kernel

While Apple’s acknowledged this issue given their knowledge base article, I still felt it’s worth opening a bug for.

1 Response

darwinup, Apple’s Darwin Update utility

Yesterday in ##osx-server, Pepijn Bruienne mentioned having stumbled upon an OS X system binary he’d never seen before, which was new to me as well: darwinup. This tool is used (or was used – public development of it seems to have stopped around OS X 10.7) for the purpose of managing versions of OS X system components by installing “roots” distributed in a variety of ways. It abstracts several different archive formats and wraps tools like curl, tar, rsync to perform its tasks.

It can install and remove packages installed via rsync-able locations and HTTP(S) URLs, and keeps track (in an SQLite database) of its activity and overwritten files such that it can roll back installations of system components to previous versions. I’ve seen it included on OS X systems as far back as OS X 10.7 (Lion) up through 10.10 (Yosemite). My immediate reaction was that this was like a basic package manager that’s included with every copy of OS X.

Digging a bit further, this tool is part of the DarwinBuild project, whose public development seems to have stopped around 10.6/10.7 (like most other macosforge projects). According to their notes, it is definitely not a package manager, however. These notes contain a much more thorough explanation of the tool than its manpage, so I’d encourage you to read through it if you’re interested in why the tool exists. The manpage has a few useful examples, such as installing components from Apple’s (similarly-abandoned) Roots repository. This repo of compiled OS X components was also completely news to me.

The darwinup tool obviously exists for testing and development purposes, so I would highly not recommend installing Apple’s old roots onto a system you care about, because they are now so outdated and could overwrite critical system components with incompatible versions. Of course, you can always roll back..

Here’s an example of installing compiled bootp tools from 10.7.2. You can also add additional -v options to print out more details about exactly what it’s doing with network and files-on-disk activity.

$ sudo darwinup install

A /AppleInternal
A /AppleInternal/Developer
A /AppleInternal/Developer/Headers
A /AppleInternal/Developer/Headers/BSDPClient
A /AppleInternal/Developer/Headers/BSDPClient/BSDPClient.h
A /AppleInternal/Developer/Headers/DHCPServer
A /AppleInternal/Developer/Headers/DHCPServer/DHCPServer.h
U /System/Library/SystemConfiguration/IPConfiguration.bundle/Contents/Info.plist
U /System/Library/SystemConfiguration/IPConfiguration.bundle/Contents/MacOS/IPConfiguration
U /System/Library/SystemConfiguration/IPConfiguration.bundle/Contents/Resources/English.lproj/Localizable.strings
U /usr/lib/libBSDPClient.A.dylib
U /usr/lib/libDHCPServer.A.dylib
U /usr/libexec/bootpd
A /usr/local/bin/bsdpc
A /usr/local/darwinbuild
A /usr/local/darwinbuild/receipts
A /usr/local/darwinbuild/receipts/bootp
A /usr/local/darwinbuild/receipts/fb5424a830958c1b4cc8191de7b8c6e9d31f1aaf
U /usr/sbin/ipconfig
U /usr/share/man/man8/ipconfig.8
Installed archive: 2 bootp.root.tar.gz

$ sudo darwinup list

Serial UUID                                  Date          Build    Name
====== ====================================  ============  =======  =================
2      17FEFDD5-E202-485A-B429-E5407881A845  Jan 21 11:33  13F34    bootp.root.tar.gz

Note that the build number is not that of the root that was installed, it’s the build of the currently-running system (10.9.5).

Now let’s run the bsdpc utility that was just installed into /usr/local/bin to display info about available NetBoot images:

$ sudo bsdpc
Discovering NetBoot servers...

NetBoot Image List:
   1. DeployStudio-10.10-1.6.12 [Mac OS X Server] [Install] [Default]

Again, use this with care. We can see that these bootp tools installed system components in addition to executable binaries (from a 10.7 system onto a 10.9 system), so this is just a demonstration of the capabilities of darwinup. Don’t do this at home!

Tagged , , | Leave a comment

OS X admins: your clients are not getting background security updates

Have I got your attention? The more accurate (and longer) qualifier for this title should actually be: “admins who configure clients to not automatically check for software updates.”

From recent discussions in ##osx-server, some of us have determined that OS X’s “system data files and security updates” will only install automatically if a client is already configured to automatically check for updates. Many sysadmins managing OS X clients tend to disable this setting so that they can control the distribution of these updates, but aren’t aware that their clients are now no longer receiving Apple’s background updates for at several of its built-in security mechanisms, including XProtect and Gatekeeper.

Rich Trouton beat me to this post with his post yesterday, but it prompted me to do a bit more digging into trying to reproduce an issue that comes up when attempting the most obvious workarounds for this issue, which I’ll outline after giving some more context.

Update: Greg Neagle has come up with a simple but flexible workaround for the issue described below, which he’s implemented in Reposado and documented here. If you use Reposado (and you really should), look into the new --remove-config-data option that can be applied selectively to SUS updates you’re mirroring.

Read More »

Tagged , , | 11 Responses