Archive for February, 2012

Building a Grand Unified Xcode 4.3 installer

February 17, 2012 3 comments

Apple has released Xcode 4.3 through the Mac App Store for all Macs running 10.7.3 and higher. In a break from the “installing an installer” method that Apple used for Xcode 4.1 and 4.2, the App Store is now installing Xcode as a self-contained application. This application, on first launch, then installs the other Xcode tools. The command line tools can be installed separately through the Xcode preferences, in the Downloads section.

For my users who are developers, I wanted to include Xcode 4.3 in their new machine builds and also install the command line tools automatically. To do this, I used a modified form of the methodology referenced in this post to repackage Xcode 4.3 for distribution without needing an Apple ID. See below the jump for the procedure.

Read more…

“What Do You Mean, It’s Gone?!?” in MacTech’s February 2012 issue

February 15, 2012 Leave a comment

For those interested in protecting their data in the event that their Mac goes missing, I have an article in MacTech’s February 2012 issue. It’s titled What Do You Mean, It’s Gone?!? – Safeguarding your Mac’s data when the Mac is lost or stolen and is a guide to help make sure that, if you and your Mac are involuntarily separated, your main worry is finding the money to replace the hardware.

Categories: MacTech

Setting a text-only login banner at the FileVault 2 pre-boot login screen

February 9, 2012 10 comments

I got a notification today from Apple that one of my long-standing bug reports had been closed out as fixed. The bug report was Bug ID 9226657 – Need to set login banner on pre-boot login screen for encrypted Macs. They also pointed me at a new Apple KBase article, with a publication date of February 9th, 2012.

This has been a long-standing feature request of mine, so I’m glad to see it’s now been addressed. That said, there are some limitations to be aware of. See below the jump for the details.

Read more…

Modifying JAMF’s NetSUS to host DeployStudio NetBoot boot sets

February 7, 2012 9 comments

Gary Larizza updated his NetSUS appliance write-up earlier today, to include information on how to modify the NetSUS’s /var/www/webadmin/scripts/ so that it can accommodate DeployStudio’s NetBoot sets.

Gary’s way is elegant and uses vim. Consider this the illustrated version that’s doing the same process the hard way with nano. See below the jump for the details.

Read more…

Converting JAMF’s NetBoot/SUS Appliance to VMWare

February 6, 2012 8 comments

I was really excited to see that JAMF released a new Ubuntu-based VM that hosts Reposado and diskless NetBoot today. I was less excited to see that the VM was in VirtualBox’s Open Virtual Appliance format. Nothing against VirtualBox, but I’ve already got VMWare installed and prefer to use that instead.

Fortunately, it is possible to convert from .ova to .vmdk pretty easily using VMWare’s OVF Tool. See below the jump for how you can convert the file and use it in VMWare Fusion.

Read more…

Protecting yourself against Firewire DMA attacks on 10.7.x

February 5, 2012 6 comments

There’s been a recent flurry of news about how Macs are vulnerable to Firewire DMA attacks, following a news release by Pressware that the newest version of their Passware Kit software can decrypt FileVault.

There’s good news and bad news here. The bad news is that, under certain circumstances, it is possible for an attacker to use the Firewire port on your Mac to extract passwords and other information.

The good news is that there are defenses against these attacks. In fact, Apple has built pretty good defenses in Lion at the kernel level, as long as you’re running 10.7.2 and higher. Based on the testing shown here, the main time that 10.7.2 or higher is vulnerable to a Firewire DMA attack is when someone is logged in and the screensaver lock isn’t engaged. Even better, this protection applies whether or not the Mac is encrypted with FileVault 2.

That being said, enabling FileVault 2 encryption on a laptop should take away the option to not lock your screen, so that should secure a 10.7.x FileVault 2-encrypted laptop completely against Firewire DMA attacks unless you’re OK with someone plugging in a Firewire cable into your laptop while you’re logged in and working.

If you really want to make sure that your Mac is secured (after all, Thunderbolt’s DMA vulnerabilities are still being explored), I recommend enabling FileVault 2 to encrypt your boot drive. Once enabled, run the following command to have your Mac hibernate (where the contents of the RAM are written to disk) and also have your FileVault 2 key automatically removed from the saved RAM state when you put your Mac to sleep:

sudo pmset -a destroyfvkeyonstandby 1 hibernatemode 25

A description of what this command does can be found here.

Once the sleep settings are changed by the above command, you’ll notice a few changes in how your Mac goes to sleep:

1. It’ll take longer – Your Mac is writing everything in RAM to disk. Depending on how much RAM you have and how fast your hard drive is, this may make the sleep process take a couple of extra minutes longer than you may be used to.

2. Your Mac won’t wake when you open the screen – Lifting the lid of your laptop won’t wake a Mac from hibernation. You’ll need to press the power button like you would if you were starting up your Mac.

3. You’ll need to enter your password twice when waking – Because your Mac’s FileVault 2 encryption key was removed from memory, when you wake your Mac it’ll look like you’re back at the FileVault 2 pre-boot login screen (though just your account will be showing.) This is because the Mac needs you to re-enter your account password to unlock the encryption and allow the contents of the saved data to be written back to RAM.

Once the contents of the saved data are back in your Mac’s RAM, you’ll be prompted for your password again. This password will be for your screensaver lock, which has engaged because your Mac has woken from sleep.

One thing to be aware of is that, as of 10.7.1 and 10.7.2, there was a bug where setting the above pmset command could cause the occasional kernel panic when the Mac was returning from hibernation. Apple knows about this and is tracking it as bug ID 10278935. If you experience it, please report it to and reference that bug ID. That said, I have not seen it as of yet in 10.7.3. Hopefully, that means it’s now fixed.

Update – 2-12-2012: It took about a week to show up, but I’ve now had two kernel panics when returning from hibernation. Looks like this bug hasn’t been squashed yet.

%d bloggers like this: