Security

Using SuperDuper! for FileVault2 System Volumes

Gregory Ruiz-Ade, , , , ,

Since my first Mac (an Aluminum PowerBook G4), I had relied upon SuperDuper! as my backup method for my Mac notebooks. It’s a wonderful tool, and faithfully replicates an entire volume, including making it bootable, for a worst-case drive failure scenario. I’ve used it for migrating my system to a new disk when doing disk upgrades, transferring an image to a new/replacement notebook, and just plain backups.

I’ve long since switched to using CrashPlan for my backups. CrashPlan has worked wonderfully, and saved my bacon a number of times. I use it on every computer I own. Crashplan isn’t, however, an ideal solution for migrating data to a new drive when upgrading your hard disk, simply because it’s rather slow to restore a lot of data over the network.

So, back to SuperDuper! I go, as I’m planning to add an SSD to my current MacBook Pro, and re-instate the “build a DR boot volume on an external drive” policy at home. The wrinkle is that since the upgrade to OS X Lion, both my wife’s and my notebooks are using FileVault2 for full-disk encryption. Given the sheer amount of personal information on these computers, it’s the only sane thing to do, especially when the notebooks are bound to iCloud, with Find My Mac enabled. (This gives you remote-wipe capability on your notebook, which is very useful if it’s lost/stolen.) Unfortunately, there’s no clear way to use SuperDuper! with a clean hard drive and end up with an encrypted volume that duplicates the original.

At least, not directly within SuperDuper.

All is not lost, though, as there is a way to do it, and get a fully encrypted, bootable duplicate of your FileVault2-encrypted OS volume!

In short, the procedure is:

  • Install OS X Lion to your destination hard drive
  • Activate FileVault2 on the new install
  • Reboot to your normal startup disk
  • Use SuperDuper! to “Smart Update” the destination
  • Boot from the destination (SuperDuper! target) disk again
  • Open System Preferences -> Security, and click on the FileVault tab.
  • Click the button to enable users to unlock the volume, and enable any additional accounts (if you have the users there to type in their passwords.)
  • Reboot to your normal startup disk again
  • Pat yourself on the back! You did it!

I’ve tested the procedure on my old MacBook Pro, from which I’m preparing to remove the SSD to transplant it into my new MacBook Pro. It works, it boots from either volume, and they’re both encrypted (granted, with different recovery keys, as one would expect). I’ll post a followup in about a week complete with screenshots of the whole process when I migrate my OS volume to the SSD in my new MacBook Pro.

Stay tuned!

Using SuperDuper! for FileVault2 System Volumes

Balance (Security vs. Usability)

Gregory Ruiz-Ade, , , , 1 Comment

I suppose this should be filed under “Get More Pageviews”, but nonetheless, I took the click-bait to Sophos’ calling Apple out on making the iPhone 4S safer to use while driving easy to access by bypassing your passcode. My main issue is that they take what is a legitimate concern regarding the tradeoffs between security and ease of use (and even safety of use while driving) and instead paint it as a deliberately cavalier attitude towards data security.

What’s disappointing to me though is that Apple had a clear choice here.
They could have chosen to implement Siri securely, but instead they decided to default to a mode which is more about impressing your buddies than securing your calendar and email system. →

You see what he did there?

Ever notice how an expert in a certain field will only ever see choices from the perspective of that field? Interesting how there is the assumption that the only options were secure and insecure. It’s like he just assumes that nobody will ever try to use a phone while driving, something that seems like it would gain a huge safety improvement by reducing phone interaction.

On my lowly iPhone 4, if I want to call my wife while I’m on the freeway to see if I need to stop at the store, I’d have to:

  • Pick up the phone
  • Press the home button or the power button
  • Swipe across the bottom of the screen
  • Tap in my passcode, or, as suggested in the Sophos article, my complex alphanumeric-with-symbols password
  • Tap the Phone icon
  • Tap the Favorites button if it’s not already on the Favorites page
  • Tap my wife’s entry

With an iPhone 4S and Siri, I’d presumably need only to:

  • Pick up the phone
  • Tap the button that activates Siri
  • Speak: “Siri, call my wife.”
  • Acknowledge Siri’s confirmation of my request by saying, “Yes.”

I wouldn’t ever have to look at the phone. The only touch target I’d need is a physical button on the phone, which is easy to locate without looking. It’s only marginally more complicated than asking a real person sitting in the car with you to dial the phone for you, because you have to push a button two times. I’m reasonably certain it’s this use case which Apple designers and engineers had in mind when setting the default options on the iPhone 4S, with the assumption that the security-conscious people could find and disable the “enable Siri while iPhone is locked” option themselves.

After all, while the iPhone is a popular device for businesses, it’s not the only market Apple sells to. Apple is going to make the choice, every time, to make it’s products easy and delightful to use for its primary customer base.

You know, ordinary people.

Balance (Security vs. Usability)

Did you leave the parking brake on?

Gregory Ruiz-Ade, Leave a comment

Just a reminder, when you’re migrating a lot of data and configuration information to a new machine, remember to make sure you pull all the relevant information.

I just spent the better part of my afternoon/evening chasing down a problem where a user could not log on via SSH. He had the right key. He were using the right passphrase. His account existed in /etc/passwd, and he was listed in the right groups in /etc/group. We did all sorts of debugging on his client, and then a clue popped out when we ran the server in debug mode:

Access denied for user dude man by PAM account configuration

Well, I thought it was a clue. Turns out there was nothing overtly obvious about what was going on. Nothing, that is, until I finally decided to check the contents of /etc/shadow, only to discover that the user in question had no entry there.

Remember to check the simple things first. For a Unix/Linux account to be happy these days, it needs an entry in both /etc/passwd and /etc/shadow! It’s a step that is only really missed when you’re copying the contents of these files from another machine, instead of using built-in utilities (useradd, groupadd) to create user accounts.

Did you leave the parking brake on?

LDAP, SSH and Access Control on Linux

Gregory Ruiz-Ade, , ,

I was recently asked for my opinion on options for adding access control, or, more specifically, host-level authorization for users connecting to Linux systems. All the systems in question are a variety of CentOS, and all of them are configured to use LDAP for authentication and authorization via the pam_ldap and nss_ldap modules.

The Problem

In a default configuration, pam_ldap and nss_ldap will make user and group accounts in LDAP act just like user and group accounts in /etc/passwd, /etc/shadow and /etc/group. If it is present, it’s a valid account for the system. In the general case, this is a good thing, and simplifies the configuration of your systems. Things get complicated, however, when you only want a subset of users to be allowed to log in to specific machines. Traditionally, the method for doing this has been to force pam_ldap to examine the LDAP entry for the user trying to authenticate, and only allow the authentication to succeed if some attribute of the user’s object matches a configured value. The host attribute of the account objectclass is a great one to use, but if your user objects are based on person or inetOrgPerson, and you’re doing the right thing and have strict schema checking, you can’t use it. You’d either have to violate your schema and disable checking, or violate your schema and add the extensibleObject objectclass, which is basically a schema-valid end-around to schema checking.

There are similar tradeoffs for other object attributes you might choose for utilizing for access control, especially considering that you can only use attributes that exist in your users’ LDAP objects, and not outside them. While it certainly can be done, and I have done it in LDAP implementations before, there’s never a truly clean way to implement the policy, and changes to the policy induces the risk of breaking the host’s LDAP configuration entirely.

A Good Solution

In the case I was most recently asked about, the only way to gain access to the system is via SSH. The application stack which the hosts run either doesn’t do any user authentication, or handles it itself. Taking a step back from LDAP, then, there is an easier way to do access restrictions: the OpenSSH daemon’s AllowUsers and AllowGroups configuration directives.

Utilizing the capabilities of OpenSSH takes one piece of complexity out of the already complex LDAP client configuration, and moves it into a service that is a lot easier to repair should something go wrong. This is especially true if you are utilizing a configuration management (CM) system like CFEngine, Puppet or Chef, where the ability of the CM to do anything might completely hinge upon the system user and group databases being intact. A configuration error that causes people to not be able to log in via SSH is less serious than all of your systems user and group records disappearing, which can completely unhinge your system.

Finally, utilizing OpenSSH’s AllowUsers and AllowGroups let’s you manage access to hosts simply by modifying group memberships of users, which can be easily done in LDAP with tools such as my personal favorite, the LDAP Account Manager. This nicely avoids the possibility of having to write your own management tool for access control to add/delete/modify attributes that aren’t easily handled by existing tools, or may not even be visible to those tools. Saving time and effort is key to sanity as a systems administrator, and this will save you a lot.

The best part, though, is that this method works regardless of whether you use LDAP, NIS/NIS+, rdist /etc/passwd and friends from a master copy, or any other method of pushing user and group account data out to your hosts. On top of that, there’s nothing saying you can’t layer this on top of LDAP ACLs, too, for that extra bit of paranoia.

Loose Ends

There are, however, some downsides to doing access control via OpenSSH. The first is that it only applies to OpenSSH. This may seem like a statement of the obvious, but it’s important to point out. Other services you may be running, which also rely on LDAP for authentication and authorization, will not be beholden do your policies configured for OpenSSH. Again, it may seem like I’m simply re-stating the obvious, but consider:

  • Do you run an FTP server with user accounts?
  • Do you run an IMAP or POP service?,
  • Do you run SMTP AUTH?

Those are just three examples, but any service you provide that performs user auth and does so via PAM, SASL (backed by PAM) or directly with LDAP would need to have it’s own ACLs in place if you don’t want all your LDAP users to have access.

With that in mind, however, if your needs are simple, use a simple tool, and get the job done with less stress.

Happy hacking!

LDAP, SSH and Access Control on Linux

Spotlight “All Images” search leaves no stone unturned

Gregory Ruiz-AdeLeave a comment

It may not be a good thing, depending on what you try to hide on your computer. 🙂

Spotlight search in CoverFlow mode

After seeing it reported elsewhere that Spotlight’s “All Images” search on Leopard really does serve up every image on the system, I decided to give it a try myself and see what turned up. Sure enough, every single piece of spam I’ve received in the last week that included an in-line image (as a MIME attachment) ended up contributing to the show.

In this screenshot, you can clearly see all the images from the spam messages. The on of the woman in the hammock is actually from a spam message, if you can believe that. No idea who she is, but whatever email message that image was sent in got filed as spam.

Spotlight “All Images” search leaves no stone unturned

Leopard firewalling

Gregory Ruiz-AdeLeave a comment

A quickie for those that want to actually get their hands dirty with OS X’s ipfw firewall: WaterRoof seems to be the tool for configuring an ipfw firewall, setting a startup script for it, etc. for Leopard. One of the nice things is that it comes with a few rules sets that make getting the basic firewall quite simple.

I’ve simply turned off the Leopard “Firewall” for now, and reverted to the tried-and-true ipfw firewall instead.

Leopard firewalling