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."

Comments

Is this a joke?

[Anonymous Coward]

Page 1: "Install Leopard."
Pages 2-250: "This page left intentionally blank."

Re:Is this a joke?

[snowraver1]

Was that a Joke? If so, it wasn't funny.

Re:Is this a joke?

[oahazmatt]

Page 1: "Install Leopard." Pages 2-250: "This page left intentionally blank." Thank you for enforcing the stereotype that all Mac users believe they are completely invulnerable because of a perference in computing.

As it is, there is a great false sense of security that comes with owning a Mac. It's like Anti-FUD. Most of it comes from a believe that the OS is "just safe", when that's not the case, especially now that programs like Darwine can run your Windows executables right out of the box. The lack of general malware can most likely be attributed to the Mac OS X file structure and the lack of a significant market share.

Anyone who owns any computer should pay attention on how to keep themselves and their systems safe.

Mac Realist since 2001

Re:Is this a joke?

[Anonymous Coward]

page 207 of 240
Installation Action Items
  " Do not connect to the internet"

Re:Is this a joke?

[Arcane_Rhino]

LOL. Ya gotta admit, this does enhance security.

They lied!

[BlueCollarCamel]

[utter sarcastic shock]And here I was told they were perfectly safe out of the box! Thanks a lot mac fanboys![/utter sarcastic schock]

Re:They lied!

[zanyterp]

or it is there to help add additional security to those of us paranoid ones not comfortable with the level of security that is already there. though it is slightly....disconcerting on one hand that they have to release such a thing; but on the other it is nice to see that they are accepting that nothing is 100% secure out of the box and that there are steps that can be taken to help with security. Any computing system that has left the box is unsecure; it is just a matter of degrees.

Re:They lied!

[tbuddy23]

That is why on my grandmother's machine I put a hardware lock, set firmware password, enabled stealth network mode and secured virtual memory. I will be damned if those dirty hackers find out which bunt cake recipes she has been looking at.

Re:They lied!

[jo42]

Excellent!

1) Read 250 pages.
2) Charge $NNN an hour for "Security Services".
3) Profit!!!

Re:They lied!

[zanyterp]

exactly! :)

Re:They lied!

[ushering05401]

On a less sarcastic note...

Documents like this will encourage people like me to at least look at Apple when considering purchases.

I have never trusted the 'so safe you don't need protection' argument about any product, much less one as important as a computer operating system. Let's not even dig into the can 'o worms of trusting a publically traded, and therefore profit driven company, to maintain the highest production standards indefinitely.

Security vulnerabilities just take time to evolve, they will find everyone sooner or later.

Re:They lied!

[Free the Cowards]

Security and safety are not binary properties. Macs are perfectly safe out of the box, particularly if you're talking about security from remote exploits, which is how people generally use the term. But if you want to take it further and get even more out of it, this is how. It's probably mostly an exercise in paranoia, although I imagine there are quite a few tips in there which will help prevent data loss in the event that the machine is physically stolen.

Re:They lied!

[wass]

What are you talking about? Even OpenBSD has security-related documents and manuals. While OpenBSD is super safe for the out-of-the-box install, any time you open a port or enable a daemon, you are exposing yourself to some kind of vulnerability if you don't know exactly what you're doing.

Mac OS X is the same way. If you're enabling advanced services and whatnot, as per the experts this manual is aimed at, you need to know what you're doing. This manual addresses that.

Re:They lied!

[El Icaro]

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.

Re:They lied!

[linuxpyro]

Just don't turn on SSH and set all your passwords to 'password'.

Re:They lied!

[99BottlesOfBeerInMyF]

Documents like this will encourage people like me to at least look at Apple when considering purchases.

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 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 released for Tiger. In any case, this guide probably should have little to do with your purchasing decisions.

Re:They lied!

[ushering05401]

Thanks for the links... My point, which I failed to express clearly now that I reread, was that the attention from the vendor was welcome.

I was unaware of the previous Tiger hardening guide from Apple, but had seen other materials from third parties. Long story short, I thought the oft repeated community attitudes towards OS X security were echoed by Apple: namely that there was little need for security measures.

Re:They lied!

[Anonymous Coward]

I am using OpenBSD as my main desktop and haven't had to open useless server daemons.
Why most Linux distros enable those by default is beyond reason and logic. It's Windows 95 all over again.
Also, when you do enable something in OpenBSD you read the documentation, you don't learn to type $sudo fewbar -nosmorking 123.156.34.5 from some seedy forum on the Internets.
MacOS X could be nice if it didn't have that ugly GUI, but I doubt it can be as secure as OpenBSD if you don't burn the computer network cards.

Re:They lied!

[99BottlesOfBeerInMyF]

Long story short, I thought the oft repeated community attitudes towards OS X security were echoed by Apple: namely that there was little need for security measures.

I'm not sure you should completely abandon that conception. Apple's attitude towards security has been a bit erratic. My perception is that the old-school Apple developers and UI gurus pay little attention to security and some projects are dominated by such people. On the other hand, the people from Next and who were hired on for their UNIX experience care a lot more about security and projects they dominate fare much better.

Apple has certainly been taking steps towards better OS X security. FileVault is functional, if not perfect and OS X in general seems to have at least some security review going on for default settings. They added secure deletion and support for security cards (probably requirements for government purchases). Their new Mandatory Access Control framework and application signing frameworks in Leopard show they are committing resources to proactive security improvements, even ones that their user base as a whole really doesn't need yet. I actually have more hope for MAC in OS X than in Linux, since Jobs can make the hard decision to require it for all new software, whereas there really doesn't seem anyone capable of doing the same for Linux and consensus is hard to reach.

Re:They lied!

[martinw89]

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.

They do

: )

Re:They lied!

[Maserati]

Exactly. Well, it's a Unix, so you can secure it properly, so you should secure it. It's nice to see a vendor-approved guide to doing it that accounts for their own quirks (especially critical in the Unix realm). Scanning the NSA guide for Linux might help too, unless they did an OS X version. And is anyone else waiting for a 4th edition of Essential Unix Systems Administration ?

Re:They lied!

[Ilgaz]

I remember running shell scripts on Slackware which will tweak lots of settings, directory permissions to more secure settings. (TIGER for Linux I think)

As Leopard has ACL out of the box, there could be some wonders to secure the machine but people aren't that advanced to do it. There is also risk. Even if I knew a single line chmod or acl command to bring wonders to security, I wouldn't post it to web as some may copy it wrong and blame you for breaking their OS.

For example on pre Leopard, just making ~/Input Managers root owned may prevent lots of future troubles. It is pro-active , doesn't require any CPU and still, Apple didn't simply do it with a security update. Instead they made Input Managers Admin owned and root dir exclusive (/Library/Input Managers). They should allow people having their own input managers in their home directory not affecting others (but secure).

We need a user friendly shell script that people may easily apply and reverse. It may require significant amount of work though. Even on Leopard, home directory is not security checked (unless when you boot from dvd), the real issue is home directory. There are some completely confused people thinking OS X is secure whatever they do and they may share their home directory with whole planet just to serve a single file.

argh: all my passwords contain a capital "U"

[peterpan79]

citing page 52:

In the Password and Verify fields, enter a new Open Firmware or EFI password, and click OK.

This password can be up to eight characters. Do not use the capital letter "U" in an Open Firmware password.

If you do, your password will not be recognized during the startup process.

;)

Re:argh: all my passwords contain a capital "U"

[kellyb9]

AND YO 'D think they WO LD have FIG RED that O T!

Re:argh: all my passwords contain a capital "U"

[3dr]

Ha!

Anybody know the reason for this?

Re:argh: all my passwords contain a capital "U"

[gEvil (beta)]

Anybody know the reason for this?

From this page on Open Firmware passwords, they list the following:
Blocks the ability to use the "C" key to start up from an optical disc.
Blocks the ability to use the "N" key to start up from a NetBoot server.
Blocks the ability to use the "T" key to start up in Target Disk Mode (on computers that offer this feature).

I wonder if the missing U has something to do with those... : p

Re:argh: all my passwords contain a capital "U"

[Anonymous Coward]

I'm guessing it's due to some Unicode support hack, although I would love to know definitively myself, just out of curiosity.

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:argh: all my passwords contain a capital "U"

[Anonymous Coward]

On Slashdot, the word "cunt" is informative. You can't make that up.

Re:argh: all my passwords contain a capital "U"

[ArsonSmith]

Apple is a US based company

Only in Soviet Russia, passwords contain U.

Re:argh: all my passwords contain a capital "U"

[Anonymous Coward]

Anybody know the reason for this? It's a side effect of the "encryption" on the stored password (xor with x'55).

Re:argh: all my passwords contain a capital "U"

[Maserati]

Now that's my kind of Easter Egg !

Re:argh: all my passwords contain a capital "U"

[ArsonSmith]

yea, _nicode has some issues like that.

Re:argh: all my passwords contain a capital "U"

[Anonymous Coward]

In any case, remember that Open Firmware is only used on PowerPC machines, and is based on a Forth interpreter.

And on Sun SPARC and IBM POWER machines. Being interpreted means that drivers (on PCI cards, for example) can be portable across platforms.

Open Firmware is described by IEEE 1275 and open source implementations are available.

Ooooh

[Anonymous Coward]

For experienced users and familiar with terminal and command-line. What does that mean to 'normal' users?

Re:Ooooh

[Darkness404]

For "normal" users OS X is very secure, why? Because when you see why most spyware gets downloaded it is either via A) Active X and drive-by-downloads or B) various freeware programs. With OS X, because it doesn't have IE Active X and drive-by-downloads are eliminated and most mac freeware is virus/adware free.

Re:Ooooh

[argent]

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.

Re:Ooooh

[Hatta]

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.

What's the point of that?

Re:Ooooh

[argent]

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.

Re:Ooooh

[KeithIrwin]

If FTP links are activated in the Finder then they become part of the file system. As such, they are treated like local files. Certain exploits in the past have allowed remote users to cause local programs to be executed. By combining these two things, they could successfully run arbitrary code on your computer by getting you to load the FTP link and then using an exploit to run a program accessed via that FTP link.

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.

Re:Ooooh

[Anonymous Coward]

* 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. This makes no sense, as Mail by default saves all attachments under 10 MB or so. And it's not like opening them from within Mail is any different from navigating to the Mail Downloads folder.

Re:Ooooh

[argent]

Getting into the habit of opening attachments makes it more likely that you will open one by reflex when you shouldn't.

My experience from supporting Windows users under the malware siege of the past decade is that reflex opening attachments and downloads is the best social engineering tool virus writers have.

Re:Ooooh

[GWBasic]

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.

Hopefully the "stupid security warnings" prevent a nephew from messing with my settings or "accidentally" installing freebie cursors!

More OSX Security:

[psergiu]

http://developer.apple.com/documentation/Security/index.html

What happened to 'Secure by Default?'

[TheRaven64]

If you need to:

1. Be an experienced user familiar with the terminal, and
2. Read a 250 page PDF

then I wonder a little about Leopard's security.

Having skimmed the document, I'm a little bit less sceptical. In a lot of places it explains why the default configuration is secure (e.g. mDNSResponder uses the MAC framework to run in a sandbox, which is why the recent security hole did not apply to Leopard, while it did to Tiger, Windows and Linux). It also told me about a few features I was completely ignorant of, such as the ability to use a smartcard to unlock File Vault images and the keychain rather than a password (would be a bit more useful if Macs included a JavaCard reader). It also covers things like completely disabling WiFi and Bluetooth, which are likely only to be required by people working in the defence industry or suffering from extreme paranoia (but I repeat myself). Sadly, although it mentions the MAC framework, it doesn't give any hints about actually using it.

It also includes one thing that made me groan slightly:

Mac OS X v10.5 supports the Mac OS X v10.4 sparse disk image format created using AES-128 encryption. In my experience, this only applies to the first boot of a Leopard system. After mounting and unmounting a Tiger File Vault disk image, you will find that it is only mountable in Tiger. I wasted many hours fixing this problem after upgrading.

Re:What happened to 'Secure by Default?'

[Anonymous Coward]

Is there any way we can give the moderators separate "Flamebait" tags for "Actual Flamebait" and "Title Sounds Vaguely Like Flamebait"?

Re:What happened to 'Secure by Default?'

[mikael_j]

In my experience, this only applies to the first boot of a Leopard system. After mounting and unmounting a Tiger File Vault disk image, you will find that it is only mountable in Tiger. I wasted many hours fixing this problem after upgrading.

Ah yes, I remembering spending quite some time figuring out how to convert my filevault image from Tiger to a sparse disk image so I could rescue everything from my home dir (without restoring from backups that were a few weeks old), I ended up having to do this through the console as the only account I had on that machine was my own unusable account (unusable as Leopard was unable to mount the Tiger filevault image for my home dir).

I remember there were a few threads on Apple's forums dealing with this problem, unfortunately most of the tips given there were given by idiots who gave "helpful" tips that either worked or wiped your filevault image, so I decided to just do it my own way.

/Mikael

A couple of issues on the very first page.

[argent]

Better Trojan horse protection. Mac OS X v10.5 marks files that are downloaded to help prevent users from running malicious downloaded applications.

The main result of this is to train people to click "OK" to security dialogs. I have observed this trend in Windows, over the past decade as a network and system admin, and there were several users who would REPEATEDLY come to me with "I clicked the wrong button again and I think I've got a virus".

Easier network security. After you've activated the new Mac OS X v10.5 application firewall, it configures itself so you get the benefits of firewall protection without needing to understand the details of network ports and protocols.

OS X is not Windows: it does not promiscuously open listening ports unless you are serving data. Unless you have installed third party software that opens additional ports, there is nothing the firewall needs to do (and indeed it has been reported that the firewall does not actually restrict access to any standard ports), and there is little point in running it. If you have, then you need to understand network ports and protocols.

Re:A couple of issues on the very first page.

[99BottlesOfBeerInMyF]

Better Trojan horse protection. Mac OS X v10.5 marks files that are downloaded to help prevent users from running malicious downloaded applications. The main result of this is to train people to click "OK" to security dialogs.

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.

Re:A couple of issues on the very first page.

[argent]

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 is NOT what the dialogs say. This is not the "OK/Cancel" problem in any way, shape, or form.

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. But every new release of OS X adds more of them, and almost all of them provide far too little protection to justify their existence.

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.

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.

Apple's design seems like a pretty good compromise to me.

Apples 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, but having put their money on stupid approval dialogs they seem unable to consider a better approach, like downloading files to a "Downloads" folder, and providing a download manager in Safari (or perhaps as a plugin for Finder, though putting it in Safari would improve thigs for Windows as well) that provides the tools to allow the user to make a reasoned decision about downloaded files on their own schedule.

I approve of Apple's ability to back out of mistakes, albeit reluctantly. That puts them light-years ahead of Microsoft, who (for example) still ship Windows with Autorun (which should be called AutoInfection) enabled. I just wish they were quicker about it.

I'd also note that the new firewall is application based, not port based.

That's potentially a plus, in that it actually forces people to become aware of ports and networking basics even quicker than I thought it would. But a minus because similar application firewalls on Windows generally get turned off pretty quickly because they are too annoying to put up with for the people who would most benefit from them. And it certainly doesn't satisfy the claim that it's automatic and invisible.

And, well, a layered defense that automatically opens the gates isn't much of a layered defense.

Re:A couple of issues on the very first page.

[zn0k]

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. Unless I am very mistaken even after quickly reviewing Apple's documentation, it is indeed an application based firewall (working off signed code, so an alert is triggered if an application's code base changes), but only for incoming connections. Thus, you cannot block any malware from contacting a control server - though you are probably blocking your machine from becoming a control server.

Re:A couple of issues on the very first page.

[99BottlesOfBeerInMyF]

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:A couple of issues on the very first page.

[argent]

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.

It's more complex than that. People aren't pigeons and even pigeons have proven more complex than Skinner thought. It's not a matter of training users to click a specific option. Users will still automatically approve these dialogs even when presented with a new dialog they haven't seen before, with labels that are unique to that dialog. It doesn't matter what the dialog says, or if the butons move around, as long as it's possible to interpret one of the options as "let me get my damn work done" and one as "if I click this I'll have to go back to square one".

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.

I think you meant to write "prevent", but since these dialogs do in fact, over the long run, cause more accidental execution of malware than redesigning the system to make them unnecessary, and once users are accustomed to being presented with "shall I do something stupid now?" dialogs they provide very little protection indeed. Not automatically opening untrusted files was a good start to fixing the underlying problem, and not dropping downloads in a folder that's full of files the user has reason to trust is the logical next step. ...sandboxes...

If the sandboxes have holes, the malware will be written to use those holes. If the sandboxes do not have holes they will be too restrictive for most any application. A sandbox strong enough to keep malware out has to, at the very least, unconditionally prevent the sandboxed application from reading or writing any file outside the sandbox, from opening any network connections except back to the server they were fetched from (the original Java sandbox design had a flaw here, because it was based on the IP address rather than the URL and would have allowed Java applets to carte-blanche attach servers through proxy firewalls... I identified this and mentioned it on the Firewalls mailing list, and as a result that was fixed), and basically being able to save ANY long term state other than cookies local only to the URL they were fetched from, or interact with ANY components on the local machine. Weaker sandboxes have been tried and have universally been found too leaky.

THAT kind of sandbox is too strict for general use with arbitrary applications.

Safari does have a download manager. It pops up whenever you start downloading a file and lets you cancel it and/or open a finder window showing it.

I know I qualified the phrase "a download manager" further than that.

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.

The first confirmation dialog boxes of this type were added (to Safari) in Security Update 2004-06-07 specifically to deal with this problem.

I posted about this in June 2004, when it happened.

Apple finally fixed the underlying problem in 2007. That's not bad, 3 years of security dialogs instead of security. Microsoft's been trying to use security dialogs instead of security for over a decade now.

You assert that they are stupid and decrease security, but you've offered no evidence.

From 1997 though 2003 I banned Internet Explorer from our site, because of Internet Explorer's leaky sandbox. The primary "protection" for this leaky sandbox was the stupid confirmation dialog. In that time a few people used IE instead of Netscape, for various reasons. In that time I had absolutely no cases of the same user going through the process of downloading an infected object to their desktop, and then running it, m

Re:A couple of issues on the very first page.

[Ilgaz]

Apple OS X marks the _executable_ files which are downloaded from internet, once only (if they weren't maliciously replaced). I saw MS copied it on XP3 completely wrong. The MS photocopy will make users click happy indeed.

If user replaces an executable by hand, e.g. new version- drag/drop overwriting old executable, it doesn't ask.

Also, if Developer is not lazy or doesn't have a philosophical reason to ignore free application signing (Adium/Omniweb has signed binaries), user is never, ever prompted when executable replaced legimately (app firewall). If the binary is hacked , the Firewall directly stops its "server" functions.

I understand the GNU command line guys but I don't get why normal .app people still doesn't sign their applications. http://adiumx.com/blog/2008/04/adium-application-security-and-your-keychain/

Presentation

[ditoa]

I have not read the document fully yet (obviously, it is 240 pages!) but I have to say Apple do a damn good job in presenting their documents. The first thing I thought when I opened the PDF was how nicely formatted it is. It is a silly little thing but I much prefer a well presented document than just text dumped. Kudos to whoever put it together, I just hope the content is as good as the presentation!

Re:Presentation

[99BottlesOfBeerInMyF]

The first thing I thought when I opened the PDF was how nicely formatted it is.

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.

Bunt cake?

[Crash Culligan]

Your grandmother bakes cakes that are sturdy enough to survive being hit short distances with a baseball bat? Watch for IP addresses from Goodyear and B.F. Goodrich, and the Michelin Man would like to subscribe to her newsletter.

First things first...

[Anonymous Coward]

All these Leoptard tips are nice and all... but how do I get past the Blue Screen of Death?

Re:First things first...

[geekboy642]

You need to upgrade your irrational prejudices. Macs get gray screens of death. Happened to my MacBook last week. It took me a whole hour to drive down to the apple store, get it fixed(hard drive replaced) by a mac genius, and drive back home. Ridiculous! A whole hour! To fix a major hardware flaw! On Windows, just futzing with driver settings to fix a blue screen would've taken four or five hours, but I wouldn't have had to drive anywhere!

Framemaker 6

[99BottlesOfBeerInMyF]

This is sort of off topic, but the PDF metadata claims it was made using Adobe Framemaker 6.0 and a Macintosh version of Adobe Distiller. That strongly implies this guide to securing the latest and greatest version of OS X, was actually put together and created using a PPC Mac running classic. I wonder what Apple plans to do in this regard going forward, since none of their currently offered systems can run this software and their are really not many alternatives for said niche. Maybe Adobe will face one more Apple product as a competitor in the next year or so, if Apple decides to bring an OS X native program to market as they have in other cases like this.

Re:Framemaker 6

[Maserati]

Apple has used Framemaker for documentation since time immemorial. There are probably a couple of people with double-digit employee numbers who stashed some of the last machines that ran Framemaker 6.0 and have the pull to keep them up and running. It's not like anyone has produced anything better than that Those people need to get a Pro version of Pages, Volumes maybe. It'd be a small market, but it'd kick in a few more doors for the sales team.

Re:Framemaker 6

[Ilgaz]

That is professional community of Apple for you. When we say Apple is wrong removing Classic support from Leopard (unless there is major tech. issue) or when they allow completely stupid rumours to spread like removing PPC from next version of OS, they mark people as troll or digg them down etc.

A professional will run whatever runs best regardless of the year it was produced. You should go to a sound studio to see all those 10.2.8 machines doing insane amounts of audio processing or 10.3.9 Machines used in million dollar AVID configurations.

I own family license of iWork 08 but perhaps Framemaker serves better for that 250 page job. I see IBM pdf documents produced by archaic software all the time too. It is not like IBM or a company having them as customer can't afford newer version/hardware either.