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."
How about this? There are several linked off that NSA page besides this one.
"Tell me doctor, with all of your defenses, are there any provisions for an attack by killer bees?"
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)
You're telling me there are no Mac users (besides myself) that can see The Mysterious Future(TM)? Very well then. Here's a preview of the next article. SuSE 9.2 is out. There, I said it. Now prepare something insightful to say. :-)
Javascript + Nintendo DSi = DSiCade
I guess you haven't heard of SELinux?
How come the NSA only publishes guidelines for the MacOS? Actually, I think that with the recent onslaught of network vulnerabilities, government organizations would do well to educate the public more about security.
In fact, where I live (Hong Kong), the government had a radio show where there would be a quick tip about securing your machine. Obviously, the focus was on Windoze, but anything that elevates the awareness of the general public to computer security is a good thing.
They did, didn't they? In the form of their own Linux distribution.
http://www.nsa.gov/selinux/
If you read the source and documentation, it's quite clear what they did. Producing a "boiler-plate" security document for all Linux distributions would be futile -- there are too many variables involved.
A commercial product such as OSX is quite a bit more linear, and this easier to release a straightforward guide.
-psy
Fortunately internet explorer is discontinued
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.
FIle Vault is actually an encrypted file system. It mounts your user dir as a volume and accesses the data on that system via the key you create.
Yes, the nature of this architecture means that there can be zero disk corruption or you won't be able to mount it. So in a normal disk corruption setting, you would lose a few files or somthing. Having your user dir as an encrypted volume forces a sort of checksum on all the data and if even a single byte is incorrect, then the whole thing fails to mount.
It's actually a very secure method of storing your user data. Performance-wise, I've noticed that you can't use iMovie to import video files to your home dir if you're using file vault. The overhead on writing to the encrypted file system is too much for my 1.3gz powerbook. The video import is all kinds of choppy. Importing to the regular hard drive is fine, though.
$5 / month hosted VPS on linux = awesome!
"Space Exploration is not endless circles in low earth orbit." -Buzz Aldrin
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.
So, what exactly does accepting a cookie have to do with security? I can't seem to figure that one out.
If you would have said privacy, you could possibly have had a point. But security? No way.
I'm probably stating the obvious, but here's the mirror:0 b9727bb43 2e622eff8e3/osx_client_final_v.1.pdf
http://mirrordot.org/stories/111603fdae3
The NSA has decided that they don't have the resources to continue putting out new lockdown docs. They're going to let the vendors do it for them. No joke.
Bark less. Wag more.
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.
I've had both problems happen (the bad and the recoverable), the bad one has not happened since I updated to 10.3.1. For the recoverable with a re-login one, near as I can tell this comes from some legacy 8 character password weirdness. As this post indicates, if you have upgraded your computer from jaguar to panther you will only need 8 characters of your password to be correct to log in. What I have noticed is that is FileVault does not have the 8 char limit and needs *all* of the characters in your password to be correct. This causes some weirdness if you have a 12 character password and have a typo in the 10th character: you will be logged in but not see any of your data. The really stupid thing is there is no error message displayed*.
Having said that, I haven't had the problem crop up in a while so they might have fixed it.
*Sort of: if you do not have FileVault on, your keychain will choke and ask for your password again.
Underloved Movies and Pub Quiz: donotquestionme.org
That part was not mentioned. However, it is not a good practice to do much of anything as an administrator, so I have to wonder if this is of any use, anyhow.
On MacOSX, running as an administrator is not the same as running as "root". On MacOSX, running as an "administrator" is more-or-less equivalent to having "sudo" privileges on a Unix box: entering your password in a security box permits you to do certain administrator-type operations for a limited period.
"They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.
They actually have their own distribution.