Thoughtful, detailed coverage of the Mac, iPhone, and iPad, plus the best-selling Take Control ebooks.

 

 

Pick an apple! 
 
Move Multiple Windows Simultaneously in Spaces

Command-drag a window in Spaces to move all windows associated with the dragged window's application to a new space. Control-drag will do the same thing, and will also preserve the same screen position in the space in which you drop the windows.

Visit plucky tree

Submitted by
cricket

 
 

Lion Security: Building on the iOS Foundation

Send Article to a Friend

It has long been a truism among tech pundits that Apple users suffer few security attacks due to relatively low market penetration making Macs uninteresting to professional cybercriminals. That may have been true five to ten years ago, but thanks to the iPhone, iPad, and iPod touch, we can now say with assurance that obscurity is no longer Apple’s primary defense against attacks.

With over 220 million iOS devices sold, Apple dominates the tablet market and is one of the major players in the smartphone market, placing the company on the front lines of the security wars. Since the initial release of the iPhone, Apple has continually added to iOS important security defenses lacking in Mac OS X to keep up with both attacks and jailbreaks. (Every jailbreak is technically a security attack used to circumvent Apple’s iOS restrictions.)

How does this relate to Lion? Before Apple formalized the name as “iPhone OS” and then “iOS,” the operating system on Apple’s handheld devices was simply “OS X” or sometimes “OS X for iPhone.” Apple representatives made the distinct point that it was merely a variant of Mac OS X, and this was reinforced once people started jailbreaking (and later developing for) the platform. While not identical, iOS and Mac OS X are more alike than different.

Apple has been extremely clear that a key goal in Mac OS X 10.7 Lion was to incorporate lessons learned on iOS back into Mac OS X. While many of these changes were focused on the user experience — gestures, Launchpad, and so on — Apple also migrated significant under-the-hood security improvements from iOS into Lion.

With Lion, Apple has focused on three significant security improvements that have been put to the test in iOS and closed one longstanding gap in how memory is protected, along with some smaller changes.

To be clear, all of these features existed in Mac OS X before Lion in one form or another; the way Apple has combined and enhanced them to change the entire Mac application and OS ecosystem clearly shows the influence of iOS.

Hardened Memory -- As I discussed in my review of the security aspects of 10.6 Snow Leopard (“Peering Inside Snow Leopard Security,” 27 August 2009), Apple failed to implement ASLR completely. ASLR, which stands for Address Space Layout Randomization and is called Library Randomization by Apple, is a powerful security control that, when used in concert with other memory protection technologies like Data Execution Protection, makes it much harder for an attacker to compromise the operating system.

To review quickly, ASLR randomizes the memory locations of operating system and application components. This slows or stops attackers because even if they use a buffer overflow (or other memory corruption vulnerability) there are no known locations to hook into and exploit. It’s kind of like a burglar crawling through an open window without knowing whether it opens into a bedroom or a sewage tunnel.

In Snow Leopard, Apple’s ASLR implementation failed to randomize all operating system pieces, especially the important dynamic loader process, giving attackers a solid location from which to launch exploits. Lion addresses this failing, and adds other memory protections to make exploitation quite a bit harder. (This is the one area where Lion is ahead of iOS, which is still improving its ASLR).

ASLR isn’t perfect, though. Many applications still use static memory locations, and if an application isn’t compiled as a “position independent executable” (PIE), it, as opposed to the operating system, can be the target of the exploitation. Attacking non-ASLR applications on an ASLR-enabled operating system is a serious source of exploits on operating systems like Windows 7 that have used full ASLR for years. On the upside, compiling an application as a PIE is the default in Apple’s Xcode development environment for 64-bit executables targeted to Lion. Since Lion is available only for 64-bit hardware (which includes additional security protections that are supported by Lion too), it’s now much harder to exploit Macs via memory corruption attacks.

Sandboxing and Privilege Separation -- Mac OS X has long supported sandboxing — optional mechanisms in the operating system that restrict what an application can do on your system. In recent years, Apple even used sandboxing to better protect some of their more vulnerable applications, like QuickTime. (Video players are notoriously difficult to secure due to all the different encoding methods they need to support and their high performance requirements.) Sandboxing in Lion is improved in two major ways, both of which we first saw in iOS.

First are many under-the-hood improvements in sandboxing and much more robust support for applications. Lion supports over two dozen “entitlements,” which are the things an application is allowed to do. Entitlements include functions like writing to the file system (including different entitlements for temporary files), accessing the network, and interacting with hardware like the camera and USB connections. To make this work, developers design and compile their applications for sandboxing and give either an entire application, or different subprocesses, only the minimally required entitlements to work. Should an attacker exploit an application, they are thus restricted to the entitlements that application has, unless they can in some way break out of the sandbox.

Ideally, developers break their applications into separate processes, with major components sandboxed to use only minimal entitlements. Called “privilege separation,” this approach provides security controls inside an application. For example, reading PDF files, rendering Web pages, viewing videos, and using browser plug-ins like Flash are all notorious sources of bugs and vulnerabilities. Apple has separated and sandboxed the rendering processes from the core applications for Safari, QuickTime, Preview, and all Safari plug-ins (back with Snow Leopard). Adobe has already sandboxed the Acrobat and Reader applications on Windows, although they haven’t announced plans to do the same for the Mac OS X versions.

In QuickTime, when viewing a video file, the rendering engine is sandboxed and restricted from writing files. So an attacker who exploits QuickTime would also need to find a way to break out of the sandbox before they could, for example, install malware on your hard disk.

Applications on iOS are heavily sandboxed, but a quick check on my Lion system shows that not a single application I’m running, other than those provided by Apple, uses sandboxing. Even Apple’s own Aperture isn’t sandboxed.

This will all change in November 2011 when Apple implements the second major change to sandboxing and requires it for all Mac App Store apps. We don’t know how carefully Apple will review individual sandboxing implementations, but at a minimum all apps submitted to the Mac App Store starting in November will have to enable sandboxing and will be less useful as a launch point for attacks. These sandboxed applications will be able to interact with your Mac only through entitlements.

Developers aren’t universally thrilled with this change. Sandboxing is intrusive, and can be difficult to implement on existing code. It will even be impossible to sandbox certain applications that require features for which Apple has not yet designed entitlements. Those applications will still run on Lion, but Apple won’t allow them to be distributed through the Mac App Store, and that in turn may negatively affect sales, given the Mac App Store’s rapidly growing popularity as the source for Mac software.

Code (Application) Signing -- A software publisher can digitally sign an application using cryptography to assure the operating system that the application hasn’t been changed, and that it comes from a “trusted” source. A digital signature isn’t merely a few bits added to the end of an application saying “I made this”; it creates a secure cryptographic hash of the entire application binary that the operating system can use to detect tampering.

Thus an attacker can’t modify a signed application without breaking the chain of trust for its digital certificates — which means Mac OS X would refuse to launch the tampered application. To upload a compromised application to the Mac App Store, an attacker would need to sign their compromised version with the publisher’s private key and resubmit the “update” to Apple for approval (which would of course be withheld).

Application signing has been used since 10.5 Leopard, on an optional basis, for a mix of security and usability functions. For example, certain permissions (like accessing the keychain) are managed on a per-application level. Once an application is granted access to a keychain item, Mac OS X records its signature for future access to that same item. If the application is upgraded but signed with the same signature, the keychain does not need to prompt again to allow access from the new version. In Leopard, application signing played a similar role in managing per-application firewall privileges.

Code signing is mandatory for all Mac App Store apps, just as it is for all iOS apps. However, unlike iOS, there is no system-wide requirement for code signing. But code signing does assure users that apps from the Mac App Store haven’t been tampered with. The key here is not that code signing is new, but that, thanks to the Mac App Store, developers have significant incentive to implement it, and the more apps that do, the fewer can be exploited through modification.

Apple is also now using code signing more extensively for its own applications and operating system components, and it has enhanced code signing in Lion to tie it more tightly to sandboxing. Developers now have more flexibility in how they sign their code and different code components, and how those tie into sandboxing.

FileVault 2 -- FileVault is another longstanding feature of Mac OS X, but probably the one where we see the most dramatic changes with Lion. Previously FileVault would encrypt your home directory, thus protecting any sensitive files and other personal information. Combined with another feature that also encrypted virtual memory, FileVault offered reasonable protection.

But that protection came at a cost. FileVault encrypted home directories by converting them to encrypted sparse image (and later, sparse bundle) files. Each encrypted home directory was thus stored on disk as a single large encrypted file, and was highly prone to corruption. This approach also broke many backup applications, or forced them to use ugly workarounds. For example, Time Machine could back up encrypted home directories only when the owner was logged out.

Many users turned to third-party products to close this gap, but there weren’t many on the market, and some (especially PGP; see “PGP Whole Disk Encryption and PGP Desktop Professional 10.0,” 14 May 2010) had a habit of breaking with even incremental operating system updates. Contrast this to iOS, where full-device encryption has been standard since the iPhone 3GS, albeit with a few implementation flaws.

Whole-drive encryption won’t stop a network attacker, but it protects your data in case of physical loss of your drive. I recommend full device encryption for anything mobile to all my enterprise clients, but options for consumers on Macs have been pretty limited.

This situation changes completely with FileVault 2. The only thing FileVault 2 seems to share with its predecessor is a name, and use of the word “encryption.”

FileVault 2 now encrypts your entire boot disk completely transparently. You choose which users are allowed to unlock it, and only those users can boot the computer. It’s fast (unnoticeable to me), works in the background (even the initial encryption, unlike the original FileVault, which would lock your system for hours if you had a lot of files in your home directory), and works well with all backup tools.

Aside from your boot drive, you can now partition and encrypt new drives with Disk Utility. And, best of all, Time Machine even includes a checkbox to encrypt your backups.

You still need to be extremely careful with FileVault 2; if you forget your password, you are locked out of your drive forever. When you initially encrypt your system, Apple gives you two recovery options based on a 24-character code. You can write it down and use it as a recovery password, and you can store it with Apple and recover it via AppleCare after answering three user-defined security questions.

Encryption is also important for remote system wiping, one of the key security features of iOS accessed via Find My iPhone. Instead of having to format the entire drive, you just have to delete the encryption key. According to leaked information, a Find My Mac service is in developer beta and includes a remote wipe option.

Improving the Ecosystem, Not Just the System -- As I mentioned earlier, none of these changes is necessarily new to Mac OS X, and some predate iOS. Developers have long been able to sandbox and code sign their applications independently, ASLR is stronger in Lion than the current version of iOS, and FileVault 2 is a major change from FileVault, but, again, stronger than its iOS sibling.

I’ve also glossed over a number of other changes, including the XProtect anti-malware checks recently added to Snow Leopard (“Apple Responds to Increasingly Serious MacDefender Situation,” 25 May 2011), which appear unchanged in Lion, and an additional Privacy screen in the Security & Privacy preference pane that lets you control what information your Mac sends to Apple and your location services preferences.


But it’s when we take a step back that the pieces fall together and show how Apple is building security into the entire ecosystem, much as it did in iOS.

The most profound change is the combination of memory protection, sandboxing, and code signing updates with the Mac App Store. While users can still install whatever they want on their Macs, those who choose software from the Mac App Store will know (or at least benefit from the fact) that their applications enforce a security baseline that’s currently rare in even major packaged applications. Compromising applications is a major vector of attack. Almost all of the recent major attacks against users (as opposed to business applications) I’m aware of rely on flaws in applications like Safari, Microsoft Excel, QuickTime, and Adobe Reader.

While I don’t see Apple forcing all Mac users to use only the Mac App Store, I could see a future — either a system preference or even a special Mac — where some users are restricted in this fashion. Those users would be protected from malicious downloads and other tricks used to install malware. It wouldn’t work for everyone (me, for example, or any developer), but the popularity of iOS devices and the iOS App Store proves there is a very large user base that can be more than satisfied choosing applications from a walled garden.

Remember the recent MacDefender attack, which tricked users into installing a malicious application? Imagine if instead of just asking for an administrator password, a dialog informed the user that a new application was not approved by the Mac App Store, and directed them to System Preferences to override the block. Some people would still fall for it, but over time, as users are trained to focus on the Mac App Store for trusted applications, I bet the numbers would be far lower.

Some enterprises already do something similar with special “whitelisting” tools to restrict what employees can install, thus preventing malware. This strategy can be highly effective, albeit often hard to manage, depending on the habits of those employees and how strictly the rules are enforced.

Let’s be clear about Apple’s motivations here. This is clearly a case where Apple will profit from security since they get a share of every application sold in the Mac App Store. But, as someone who had to spend part of a recent weekend cleaning a relative’s Windows-based PC of malware, I don’t care that much as long as it works for users who are otherwise at risk.

The changes in FileVault 2, and the impending Find My Mac, show that Apple also recognizes the demand for better security on mobile computers. Apple has sold many more laptops than desktops in recent years, and this trend has continued even after the release of the wildly popular iPad. Although the combination of encryption and remote wiping has long been an option for enterprise users, Lion is the first time we’ve ever seen it built into a consumer operating system (even Microsoft’s BitLocker full-drive encryption is an option only in its Ultimate and Enterprise versions).

In the end, Lion is significantly more secure than Snow Leopard even without the Mac App Store ecosystem. Combine the two, and we can see a future where we have security options never before available to consumers, and, more important, where security is an integral part of the overall ecosystem such that even those who know nothing about security are well protected.

Although you must take many factors into account when deciding when to upgrade to a new version of Mac OS X, from a security standpoint, the sooner you upgrade to Lion, the sooner you can benefit from Apple’s security improvements.

 

CrashPlan is easy, secure backup that works everywhere. Back up
to your own drives, friends, and online with unlimited storage.
With 30 days free, backing up is one resolution you can keep.
Your life is digital; back it up! <http://tid.bl.it/code42-tb>
 

Comments about Lion Security: Building on the iOS Foundation

Chris Pepper  An apple icon for a TidBITS Staffer 2011-08-15 18:44
> While I don’t see Apple forcing all Mac users to use only the Mac App Store, I could see a future — either a system preference or even a special Mac — where some users are restricted in this fashion.

I wonder if Apple will add an option to prevent non-admin users from even installing non-MAS apps for their personal accounts. This would probably be tremendously appealing to many businesses, and would also greatly simplify software audits.
Charles Maurer  2011-08-16 01:14
I suppsed the App store is secure--in a sense.

Recently a friend came to visit with her iPhone. She wanted to install a piece of free software through the App store. To do this Apple insisted upon having my credit card information.

My credit-card information, not hers--for free software.

This credit-card information Apple are still keeping on file. I cannot delete it. In my country it is illegal for a company to keep credit-card information on file after a sale but Apple are in the United States.

Apple's App store is indeed an excellent form of security, but mostly because it secures Apple excellent revenues. I am sure that it secures Apple revenue even when a customer does not intend to buy anything. I would like to have a small cut of every unintentional purchase that goes through because Apple keep customers' credit-card information on file.

Anybody who is likely to be tricked into purchasing something from a phoney web site is even more likely to be tricked by Apple's App store into purchasing something that he does not want or need. (Sorry, "marketing by confusion" is the technical term, not "trickery".) To prevent unintended consequences I think it safer to ignore the App store and to set up an outgoing firewall that prevents connections to it.
Apple only require the iTunes account holder's (usually the owner) credit card details, not their friends'.
Charles Maurer  2011-08-16 13:43
Of course we tried entering her account info first but Apple would not accept it and kept asking for mine. She was logged in through my wireless network, and apparently Apple had associated that network with my account.
Adam Engst  An apple icon for a TidBITS Staffer 2011-08-16 16:12
That's very odd, and as far as I know, there is no mapping of Apple ID information to network. For instance, Tonya and I have separate Apple IDs (and thus completely separate accounts) that we use from the same network.
Adam Engst  An apple icon for a TidBITS Staffer 2011-08-16 14:23
I can't explain what you experienced, but I can say that it sounds like an error situation, not anything that's normally experienced.

I'm assuming that your friend used the App Store app on her iPhone to download this software, and if that were the case, there's absolutely no reason it should have wanted your information. I do this sort of thing all the time.

If you were trying to sync her iPhone with your Mac, then you're in for a world of serious confusion. Apple's system assumes that one account on the Mac goes with a single Apple ID, and a single person's iPhone syncs to a single account on the Mac. Plus, an iPhone can sync with only one Mac, for the most part, so if she connected her iPhone to your Mac, it would either have been confused because it was associated with your account and thus your Apple ID, or it would have been confused if you'd set her up with her own account, since it presumably synced with her Mac at home.
Charles Maurer  2011-08-16 16:37
Some confusion of this sort does sounds likely. First we tried to download the app through my iTunes and discovered that this would require synchronizing her iPhone, then we went directly to the App Store using her phone.
jimsanders1  An apple icon for a TidBITS Supporter 2011-08-17 19:15
As a retired NonStop OS/network app designer, I appreciate all the potential App Store bennies; but I have already seen one additional hidden cost to the user of all this goodness: In past, when we purchase & install a new app from the developer, license makes clear whether you can install for all users or just my own. They provide as serial number as 'key-switch' to however many copies they allow.
Now, the App is signed with Apple-ID of one user, so developers seem to have no choice about multi-user or "family-packs", and there is no choice but to buy another copy for second user of same machine. Confused about how that works with one copy of the App in Application Folder, but both signed users can use it when logged in. My wife and I maintain two separate accounts on all our non-iOS systems (3). Apple does maintain a support doc that instructs several methods how to do this, but I hope they make it smoother over time.
To Charles Maurer: go to the settings on the iPhone, then go to the "store" icon and make sure you are logged out of YOUR iTunes account, details of which may have transferred across when you tried to sync her phone on your computer. Worth a shot to see if it helps get your iTunes ID out of someone else's iPhone where it shouldn't be.
xandra  2011-08-24 03:51
This was one of the best descriptions of security in MacOSX I've ever read. Kudo's to the author.
As a developer, I'm looking forward to walled garden OS X because of the security advantages.

On both iOS and OS X, I would love to see a better compromise:
- Developer mode
- User mode

Developer mode is where all havoc can occur (i.e. development) and the OS would by default by in User mode where only signed code may run.

A per-application policy will not work. Just like iOS, OS X has to be locked down to a walled garden to ensure the common exploits are almost completely thwarted before they even appear.

Much like iOS, I'm wondering if this will lead to 'jailbroken' OS X, but that's why Developer mode would be an interesting compromise.