Apple Releases Mac OS X Leopard Security Guide 61
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."
Re:They lied! (Score:3, Informative)
Re:Ooooh (Score:5, Informative)
* 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.
More OSX Security: (Score:4, Informative)
Re:They lied! (Score:5, Informative)
- 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.
Re:They lied! (Score:3, Informative)
I understand that there are environments where the default level of security of workstations is insufficient and hardening is needed. The thing is, if you're administrating such an environment and need to harden your systems a bit more, you should already have read the similar hardening guide for OS X [nsa.gov] that was published by the NSA (or at least be aware of it since it was discussed in hundreds of security forums when released). It was for Panther at the time, but not much has changed since then, at least as far as practices. Or you could use the hardening guide [apple.com] Apple released for Tiger. In any case, this guide probably should have little to do with your purchasing decisions.
Re:argh: all my passwords contain a capital "U" (Score:2, Informative)
In any case, remember that Open Firmware is only used on PowerPC machines, and is based on a Forth interpreter. EFI is used on all the Intel Macs, and isn't subject to the same restriction on passwords.
Re:A couple of issues on the very first page. (Score:4, Informative)
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.
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.
Re:Presentation (Score:3, Informative)
Interestingly, they put it together using Framemaker v 6.0, according to the meta data. That is to say, they're using software from 2000, because none of the current versions run on Mac OS (and that version only runs on OS X using classic on a PPC system). It will be interesting to see what they transition to to retain that high quality of formatting.
Re:A couple of issues on the very first page. (Score:3, Informative)
What you are referring to is often called the "OK/Cancel problem" and is a classic HCI issue to avoid.
Absolutely not. It doesn't matter WHAT the dialogs say. The Windows dialogs I'm talking about do NOT in general actually read "OK", there are a variety of approval buttons in use, most of them completely descriptive of what they are going to do.
The problem was named back in the day when that was what pretty much all the dialogues boxes read. It is still used to describe the problem today, even though the button names have changed. The problem is operant conditioning users to reflexively click a given option. What the buttons are named is one aspect of the problem, as buttons that are not action verbs are not descriptive in themselves and those button names are the only part of the dialogue box that are "required reading" for the user to find and click something. Another aspect is if the button names are consistent for all actions or specific to a given action the user is to take. If every dialogue box in every situation has the same two option, even if they are action verbs, the conditioning aspect still occurs (just not as readily). Both of these are part of the problem, but not the entire problem. As such changing the names and making them unique partially mitigates the issue.
The problem is that unnecessary approval dialogs are being used at all. OS X's only advantage here is that there are ... for the moment ... fewer of these.
The term "unnecessary" is wholly subjective. The criteria upon which these need to be evaluated from a usability and security perspective is if they cause more or less accidental execution of malware. This requires a formal test to be certain (which I'm sure Apple performed) but the identifying of software as software (not data) is alone probably enough to justify the existence of these checks.
A sandbox that is complete enough to actually prevent malware from escaping will be too restrictive. Anything less than full MAC (orange book class B, at every level, default closed, under explicit user control) will be no better than Microsoft's sandbox for IE (which has had demonstrated failures right from the start), and full mandatory access control has proven too cumbersome everywhere it's been implemented.
Just bolting on a sandbox, obviously, would not work. That said, sandboxes can and do work today, with MAC as used on hardened Linux and Solaris workstations and, even the MAC Apple is using now to sandbox some of their default services. The trick is to make it usable enough that it doesn't get in the way, which will probably require additional work including application signing (already implemented), signatures including ACL from major developers (like the iphone but more greylisting), and a transitional phase with Apple requiring compliance from developers going forward.
It is quite possible to make sandboxing a very usable reality, it just hasn't been really needed yet except for Windows (who have failed to create workable UI, big surprise) and in high security environments, where the UIs can be less forgiving.
Users don't necessarily need to now everything software does (and will never understand such) they just have to decide who they trust and to what degree and hopefully be given the option to make use of the expertise of those they do trust.
Apples[sic] design is the result of a mistake they made in Safari in 2004... making 'open "Safe" files' on by default... and backed out of last year...
This has nothing to do with the problem we're discussing and does not seem to have influenced the design to use confirmation dialogue boxes.
...but having put their money on stupid approval dialogs they seem unable to consider a better approach...
You assert that they are stupid and decrease security, but you've offered no
Re:Ooooh (Score:4, Informative)
Re:Ooooh (Score:3, Informative)
If you change things so that FTP links are not given to the Finder, then the remote files will not be part of the file system unless you specifically choose to download them, thus preventing the second step of the attack from running the remote programs.
Although I don't currently know of any exploits which can cause local code execution, there are likely to be other ones found in the future. A typical remote exploit requires that the attacker in some manner gets a program to treat the data they give it as code and run it. However, an exploit which only seeks to run a program off of your file system would not have to do this. In such an exploit, an attacker could potentially just overwrite one piece of data with another (for example, overflowing a buffer in order to overwrite the name of a program that was going to be launched). As such, these sort of exploits are tougher to prevent since many of the hardware and OS-level techniques do not address them.
This type of exploit can also sometimes just result from immediate bugs in programs. For instance, let's say that there's a 3-D modeling program. The 3-D modeling program hooks in to an open source renderer which has been ported from Linux and runs on the command line. For certain types of files, which are not common, a special routine is used to invoke the renderer. Unfortunately, this routine has not been well tested, and it accidentally mixes up the order of the command it is going to run and the arguments to the command. Because the circumstances don't happen much, the programmer doesn't catch it, but the attacker notices it and uses this to build a web page to trap people. The web page offers a free download of a 3-D model for the program. It also launches an FTP URL.
The user goes to the web page, it launches the FTP URL, which gets mounted on the desktop. The user either doesn't notice this or doesn't worry about it. Then they open the file, play with it, and tell the program to render it. The file is crafted to trigger that special case and to have the arguments be the location of a malicious application from the FTP site (accessed through the file system). And there you go, they now can run an arbitrary program on the user's system.
This example is hypothetical, but realistic. It could also be done as an email worm. Having things set up so that FTP links do not mount on your file system will prevent this sort of attack.