Slashdot Mirror
NSA Security Guide for Mac OS X
An anonymous reader writes "The National Security Agency has just released a Security Configuration Guide for Apple Mac OS X (pdf). The guide mostly contains common sense configuration information that applies to many Unix systems. It also includes specific discussion for Apple's unique features such as Keychain and FileVault. It should be useful to most Mac OS X users and will be particularly useful for US Government organisations that use Mac OS X and for commercial IT Departments that are supporting Mac OS X. A range of other NSA Security Configuration guides for other operating systems, applications, and IT kit are also available."
Has anyone seen this before?
I finally found something about OS X that I absolutely hate and is making me question the entire OS. OS X has its own digital certificate/private key cache (which also stores passwords, but that is irrelevant), which is convenient for applications that use certificates and private keys for identity (like safari and mail.app). It also has a nice utility for managing this environment (Keychain Access).
HOWEVER, Apple (for reasons I cannot fathom) has decided to not allow keys and certs to be exported from this cache. This is totally unacceptable and horribly wrong. In this email, which confirms my worst fears, Peter Sagerson says it best:
In Jaguar, private keys are never exportable. This seems kind of silly, since my digital identity should be linked to me, not the platform, the machine or that particular (and transient) installation of the OS. In Panther, Keychain Access has an Export command, but it's never enabled. I don't see a Keychain-level API for key export and the CSSM API doesn't seem to work. So it's hard to tell what the intention is.
The intention seems to be the very incorrect idea that the digital identity belongs to the computer, and not the person. I have figured out how to move my cert and key to another Mac, that is simple creating a new keychain, copying certs to it, and moving the new keychain file to another machine. However, I still cannot get them out of Apple's proprietary format to move them to any non-OSX platform. I have posted this question to Apple's usually helpful discussion forum, but have received no answer.
This is most disturbing and calls into question both Apple's competency with regard to security in general, and their intentions with regard to what the user can do with their own data (or in this case, their own identity)
Corsaire Ltd has an excellent practical OS X security whitepaper in this same vein.
Apple is most certainly not tying digital identity to the computer.
Your Keychain, in ~/Library/Keychains, is perfectly portable, and designed to be moved from computer to computer, or stored on a device for storing such tokens, such as a USB flash drive.
Further, that certificates are even in your keychain at all implies that you should have access to the original source certificate files, which clearly remain portable.
And finally, rumor has it that Tiger will include much more advanced features for managing, importing, and exporting certificates and CAs.
Attacks on MacOS X will be driven by user interaction.
.
/Library/StartupItems.
The biggest problem for malware writers in MacOS X is that it's hard to remotely attack the box.
Mac OS 9 and its ilk were pretty much impossible to compromise remotely, because, well, they were designed as single-user OSs with no network services (no network daemons) installed by default.
Mac OS X isn't quite like that, but it's close. The downside is all those bsd-level things probably have holes of one sort or another. Has anyone actually checked the robustness of Apple's X-11 implementation?
OTOH, it's must easier to get the user to click and download something. The "prompt for your admin password" thing is great, but everyone does it without thinking these days, giving any installer root access.
Once that happens, you can install anything, anywhere, and given the structure of MacOS X you can hide your stuff in places a normal user won't be able to find. The "Opener" guys (see www.macintouch.com) should have edited the rc scripts, not stuck their stuff in
Luckily, the web/email based attacks haven't worked so far (unlike on Windows), so you really do need to get someone to run an app. These days that isn't as hard as it used to be.
Apple could protect against that by doing a system restore/diff after every installer run. It would be useful after-the-fact, and most users may not understand any of it, but it would be nice to have. Or (assuming the metadata stuff works in tiger) you could stash metadata info on the installed files somewhere, then search across your filesystem for matching stuff?
Ideally (and this is what MS tried) each publisher would sign all their files, and that sig would be part of the file metadata. So you could list, see, and search across it. Malware would bypass that, though, but you never know.
It is my understanding that on OS X, the authorization dialog pops up because a request to a protected reqource/API has been made, as opposed to an application being able to just randomly tell the OS to pop up an authorization dialog.
The dialog itself always displays the name (and if available icon) of the application making the request, as well as the name of the right being requested. As this is put together only by the OS, you can't substitute one right name when you really want to do something different. And getting one right doesn't automatically permit a process to use any other right on the system -- each right needs authorization.
It's actually quite a good system, and has been very well thought out. It does, of course, rely on some vigilence by the end user -- if they're entering their password anytime it's being requested without quickly checking to see what is making the request and why, obviously they're going to get into trouble.
Then again, if I e-mail a bunch of Linux admins and ask them for their passwords, and they send them to me, you wind up with the same end result.
Yaz.