So, when will it be more secure?

By uliwitness

In ye olde days, when someone talked about an inherently insecure operating system that indiscriminately launched downloaded applications, it was Windows. But in recent updates to the system and Safari, Apple has made similar mistakes, even the same ones the designers of Windows made. That there are no viruses for MacOS X at this point in time seems to me to be more a coincidence than a sign of OS X’s impeccable design as a secure Unix.

When OS X was first introduced, I complained that even having a console was already more insecure than OS 9. Though true, it’s like complaining having a front door makes your house more attractive to burglars, so I’m not going to complain about this. Instead, let’s look at other, worse loopholes.

Unix security and the typical Mac

Unix security generally works per-user. In the days of time-sharing mainframes with attached terminals, that was enough granularity. Even though every program ran on the same mainframe, no user could see the others’ files or run a program that did more than damage his own files. Whenever a virus is executed on a Unix system, it is bound by what the user running it can do. So, everyone talking about how Unix permissions make it impossible for a virus to do much damage, is probably talking about the whole computer. It’s true: operating system files are only modifiable by administrator users or the all-powerful root user.

However, when you look at the typical Mac user’s system, you’ll notice two things:

  1. There is only one user. The one that has been created when you installed the OS. And it’s an administrator.
  2. The files the user cares about are not the system files. It’s easy to reinstall the OS when your computer goes south. But the files that are really hard to get back are generally the ones the user created herself. And since computers aren’t a purpose unto themselves, but rather just a tool for creating correspondence, music, managing photographs or whatever, only those files are worth protecting.

To Apple’s credit, they actually managed that better than it may seem from my comment above: An administrator is by no means an all-powerful user, but instead is a user that can be made to be almost as powerful as root, but isn’t by default. So, as long as you don’t indiscriminately enter your password on a Mac, an admin account is seldom more dangerous than a regular un-privileged user account. But even that user can delete all their own files.

I can’t feel my hands!!!

The problem is that there are so many applications these days that require an administrator password. Heck, even Mail.app asks for a password (not the admin password, but still) every time something goes wrong, even if it wasn’t an authentication error. This de-sensibilises users. When an app asks for their password, they may just go: Oh, it’s mail checking for messages in the background… and just type in their password. Agreed, it is fairly unwise to have the same password on your Mac and your mail account, but it happens.

Then came Safari and started launching and auto-extracting downloaded archives and disk images, and then even launching installers in them. Finally, they made Safari auto-install Dashboard widgets. It’s a convenience, but one we already cried out about when Internet Explorer had that bug.

Apple’s fix was to start showing a dialog window saying: This archive may contain an application, do you really want to go on? whenever you downloaded an archive. But not just in the cases that were actually dangerous or before it tried to launch some app, no. They did it for every darn archive.

Like on Windows, such oodles of questions and dialog windows eventually make users stop reading what’s in the dialog window, just entering their passwords, clicking OK left and right.

Introducing … Address book, iLife and the new iTunes!

One reason why e-mail viruses such as Sober have been so devastating is that they accessed Outlook’s address book and sent themselves to everyone in your address book. Not to be trumped by Microsoft, Apple quickly caught up in this regard and gave us AddressBook.app, which allows viruses to easily query your contacts’ addresses.

Then came iLife’s resource browser, which shows us how neatly apps can be integrated. They could query your list of photographs and easily send them along to make the message look more authentic. If you don’t think this may be a problem, the new iTunes reminds you that even Apple can’t be trusted to not transfer your currently playing songs over the net…

True, iLife’s resource browser isn’t available to other programmers besides Apple’s but that’s not really important, because actually getting at the playlists and photos isn’t very hard. After all, all applications have free access to all of their user’s files.

Apple already has a solution from the Unix world to fix this: Access control lists (ACLs). Access control lists essentially allow for much more granularity on who may do what to which file. A little extension of that, and they could simply prevent all applications from reading your address book, walking your photo library, calling home via the internet or deleting your TextEdit files, except those that you actually give permission.

Yes, during the first launch or during installation you’d have to ask the user whether they want to give an app the correct permissions, and that’d confuse newbies a bit more, but with a sensible set of default permission sets, the list of things to let the app do could be as short as:

  • Send E-Mail (to your address book contacts)
  • Manage the iPhoto library
  • Access files not owned by this application

(Of course, Apple would need to find the most common permission combinations and create human-readable names for these combinations, otherwise the lists would get so long that users wouldn’t read them anymore)

If they added a more reliable and powerful facility for sending feedback and bug-report e-mails through Mail.app, and added something for updating third-party applications (like Shovel or Sparkle) to the system, most apps wouldn’t even need the first item. Users would just get a prepared E-Mail in Mail.app, with a system profile or so as the attachment, and could decide themselves whether to send it or not.

When an application tries to use a permission it doesn’t have, the OS could show a warning and offer to the user to permit/prohibit this action once or forever. So, if a screen saver suddenly wants access to your address book, you’ll know it’s a trojan… It’s definitely not an ideal situation to ask the user this many questions, but most users seldom install new applications, thus keeping them wary of these requests.

So, why all of this?

Apple needs to get access control lists adopted for such purposes quickly, before the first Mac virus hits and destroys its reputation, or even worse, users’ data. Safari needs to be fixed to not just say "There may be an application", but rather to be more precise. When you download a Dashboard widget, it should not tell you there may be an application, but rather it should ask you "You just downloaded a widget, shall I install it? It may be dangerous!". And it should not ever warn about applications when the archive only contains a text file.

I’m not a security guru. I’m just a programmer. But when even I see the glaring security holes, it’s time to act on that.

2 Comments Leave a comment

  1. I have (if you have a look at my not-a-blog linked above) been griping about this and sending in bug reports to Apple about it for a while now. But even with the idiocy of “Open Safe Files After Downloading” and auto-installing Dashboard widgets, it’s not as bad as Windows. You CAN turn off the former, and you DO have to run the Dashboard widgets… it’s not like Windows where clicking on that dialog box means you’re owned.

    Also, I don’t see that ACLs are the solution. ACLs assume that the applications themselves are immune to exploits, so if mail.app has a buffer overflow and the virus running in the context of mail.app tries to access your address book, why, it’ll be allowed to!

    The real solution is to reject the notion that there are such things as “Safe Files”, or at least files so safe that it’s worth even considering automatically opening them on download (or installing them in the dashboard, or what have you). Instead, download them, and leave their names in a download manager for the user to do something with at their leisure.

    That way opening the file isn’t the result of a time-sensitive decision that’s subject to reflex action, it’s an asynchronous step the user can perform on their own schedule.

  2. Peter,

    you have a point there. That’s basically what I started from, but it will only solve the problem IE had ages ago with its auto-opening of files. It still wouldn’t protect people from running odd files they find on their desktop that look like archives but are in fact trojans.

    In the OS 9 days, Netscape (or was it iCab?) would set the “comment” of a downloaded file to the URL from whence you’d downloaded it. I always wished all browsers did that. Now I’m thinking how neat it would be if that was possible for all data. I’ll just describe how this would work for files:

    Every file downloaded gets a special metadata attribute with the source URL. When a file that has such an URL is first opened, it shows a dialog telling the user the server and complete URL it came from (the server to avoid misreadings of stuff like google.com/page@server.com as being google instead of server.com), and asking them whether to really open this file. You could declare certain servers as “safe”. It’d help tracking down a file you downloaded ages ago, as well as being one small additional security layer.

    Badge or otherwise mark applications and files that will be executed (even if they have custom icons), give files icons corresponding to what app will actually open (even including the user override), generate icons for files whose target app doesn’t offer an icon (e.g. opening .foobar files in TextWrangler should give an empty doc icon with TextWrangler’s icon in the page area)… all these small things would help make users curious about a trojan file (‘why is the “app” badge on this word document?’).

    It still wouldn’t fight social engineering techniques, but those can only be fought through education, I’m afraid.

Share your thoughts