Slashdot Mirror
Apple Releases Mac OS X Leopard Security Guide
Wormfan writes to share ZDNet's brief mention of and a link to "Apple's release of a ~250 page PDF of security best-practices and tips to protect Mac OS X Leopard clients. The guide is aimed at experienced users, Apple says, familiar with the Terminal application and its command-line interface."
For normal users, at this point, my basic recommendations are:
* Make sure that you have 'Open "Safe" files after download' disabled in Safari.
* Use a tool such as "More Internet" to change the default application for FTP: URLs from Finder to either an FTP-aware web browser like Firefox or a dedicated FTP client.
* Consider disabling Dashboard if you have any doubt over your ability to recognize when third party Dashboard applets are installed via Safari.
* Don't open attachments from inside Mail. It's a dangerous habit to get into, the extra second spent saving them to a file is worth it.
* Don't let the stupid warning dialogs lull you into a false sense of security. These were a bad idea when Microsoft started using them, and it doesn't make it any better for Apple to follow.
http://developer.apple.com/documentation/Security/index.html
1% APY, No fees, Online Bank https://captl1.co/2uIErYq Don't let your $$$ sit in a no-interest acct.
I haven't gotten very far in it, but it is very interesting. It goes far beyond in security to what a standard user would ask for. I'd actually like to see Windows or Linux have a similar guide/compilation.
- Disabling kernel extensions for firewire, bluetooth and wifi among others (completely disabling those functions).
- Different privilege levels (not just admin, user and guest).
- Managing accounts through open directory.
- Configuring password complexity requirements.
- Managing keychains.
- Securing system preferences and services (just one click, not sure if that is a good thing though). Apparently you can lock down to the Dock size of your users. - Erasing data securely (35-pass erase? Really?).
- Disabling Safari functions (no downloads, cookies, autofill in forms, proxies, etc...).
- Managing services and running in stealth mode.
- Command-line for most of the above.
And I'm about half-ways. This is really nice to have for any serious admin. I consider myself an experienced mac user (yes, a fanboy too) and I'm surprised with everything Mac OS has that I didn't know about.
What you are referring to is often called the "OK/Cancel problem" and is a classic HCI issue to avoid. This is different from Windows though in several ways. First, OS X does not have other, identical dialogue boxes that routinely have to be clicked in order to "make Windows work". This means users are not being conditioned to click "ok" in response to any dialogue box that appears. OS X does not present useless dialogue boxes that only have the OK option to further condition users. Second, the options are not "OK" and "Cancel" like any other such dialogue box, but "Cancel" and "Open". This is better than Windows, but not ideal. Open is an action verb, one of the primary requirements for bypassing this problem. It means even if the user does not read the dialogue box, they still know what the button they are clicking is going to do, it will open something. I'd argue "Run program" would be a better label for the button, but it is not a complete disaster. Third, this option only applies to programs, not data and as such differentiates the two. This box does not appear when you double click a file from the internet the first time; it only appears when you do so with an application, making it much less frequent (less conditioning) and informing users that this is an application and not data, so they can't be tricked into thinking it is just a movie file or a zip file of images. Fourth, on Windows, when the OK/Cancel box appears, people need to choose and may not have all the information they need. On OS X, there is also a button to open the Website from which the application was downloaded, thus giving users the option of easily looking into it and helping to resist the temptation to just run it and see what happens.
To summarize, OS X does not fall afoul of the OK/Cancel problem to anywhere near the same degree as Windows, but there is room for improvement. Ideally, the user should know what is an application and what is an executable before clicking on it. Ideally, they should be able to run it without a warning and the OS should appropriately sandbox it, by default, so that it can be run safely, even if it is malware. I suspect that is the direction of the future, but we're not there yet. Apple's design seems like a pretty good compromise to me. It's not great and revolutionary, but it is better than, well, anyone else's solution I've seen.
...and there is little point in running it.With regard to Leopard's new firewall, the idea is layered security. If malware slips onto the machine, the Firewall may still be able to limit the damage it can do. If a worm can't connect to its control channel, it basically does nothing. I'd also note that the new firewall is application based, not port based. That means it can restrict some new game from accessing port 80, while allowing your Web browser to do so. Sadly, it is not used to its full potential, but having it on any running can save your butt. Just be careful to note that the new firewall is not the old firewall and running both can be better yet. There are a lot of ports I don't want to communicate on and even if I don't knowingly run a service on one, does not mean some trojan has not done it for me. The firewall is a way to detect and stop that action.
Using Finder to access FTP URLs can cause significant systematic performance problems for OS X, because Finder actually mounts them (under /Volumes/name.of.site.example.com), and errors in performing operations over FTP can cause lockups in apparently unrelated parts of the system. Worse, it displays files in an untrusted location in the Finder itself, which is an incredibly useful capability for someone designing a social engineering attack.