Installing software

Jeff, I promise this one will be short! And any MacOS fans reading, I am not dissing your OS! I am simply pointing out that this problem has no easy solution 🙂

A couple of days ago I wrote about the problems we face with usability versus security when installing software. Lucky for me, the experts over at Slashdot have come up with the answer -- just do what MacOS X does!

I will preface what I am about to say with the following: I do not own a Macintosh and I have never installed nor used iTunes. I would be very happy to hear from people who have installed and used iTunes on the Macintosh, because maybe they can explain what the experience is like.

Anyway, from what I can tell:

·       iTunes connects to the internet

·       iTunes reads and writes files to your disk

·       iTunes can be installed by typical end-users

·       iTunes is very popular (and therefore likely to be executed by eager users)

How then is the design of MacOS any more secure than Windows XP?

·       NakedCelebrity.exe connects to the internet

·       NakedCelebrity.exe reads and writes files to your disk

·       NakedCelebrity.exe can be installed by typical end-users

·       NakedCelebrity.exe is very popular (and therefore likely to be executed by eager users)

Now MacOS X may be a great operating system, but I don't see how they magically solve this problem. They still have to deal with the same two problems:

·       End users want to install software

·       You don't need to run as root / Administrator to do massive amounts of damage

Whatever steps OS X makes you go through to install iTunes (type in your password, reboot in single-user mode, stand on your head and spin three times, etc.) the user would just as happily go through to install NakedCelebrity.exe (or a Trojan pretending to be iTunes).

Oh, and in order to download iTunes from Apple, you have to have script enabled in your browser... which means I won't be downloading it any time soon.

Comments (7)

  1. I’ll comment on this. Until content can only be run within a specific context, I don’t think we’ll have any good ways to solve this problem. Example:

    iTunes installs on the machine and using a trusted certificate proclaims that it is capable of running MediaX and MediaY.

    iTunes downloads media and installs it into an OS controlled store somewhere. Unless running admin’ed this store is safe, otherwise, associate all risks of running as admin.

    iTunes then reads out content of type MediaX and MediaY in order to play it. By being signed to play MediaX and MediaY iTunes is saying it will only try to run these media a specific way (aka there is no known way to hack a machine by playing an MP3 through an MP3 codec for instance).

    If iTunes accidentally downloads crap content, it simply sounds like crap when played as music. Other applications can’t get to the content unless they are signed to run that type of content.

    The new paradigm is that an application would have to install on an end users machine, be signed to run specific types of content, in order to play anything that iTunes downloads. This process would make it at least somewhat more secure and ensure the iTunes downloaded content can’t be accessed and run as executable.

    There are so many ifs and buts in this equation though. You can marginally make things more secure over time using cool new methods, but at the end of the day you are at the whim of the user. User’s make mistakes. User’s would install software from and approve it to run anything it asked to be approved for.

  2. RichB says:

    Did you just say that you run with Active Scripting disabled?

    ie the product you help developed, you keep disabled?

  3. David Bossert says:

    "Oh, and in order to download iTunes from Apple, you have to have script enabled in your browser… which means I won’t be downloading it any time soon."

    …or taking off your tin-foil hat.

  4. David Buxton says:

    Mac OS X does not address all of these issues, but there are some differences in approach which help to reduce the damage a trojan can cause.

    Most importantly, having JavaScript enabled in a typical Mac browser is not the gaping security hole you fear. I can’t think of any Mac browser which allows a script to control anything other than the browser itself, and even then the control is restricted to the display of content, the script cannot set browser preferences. As soon as you can run AppleScript from a web page, Mac OS X will be in the same trouble as ActiveX/IE – but you can’t.

    A typical home user will be using an administrator account, which means that user is given the option to escalate privileges if desired. But most actions (including playing iTunes music) happen with the user permissions, so iTunes cannot overwrite files that the user cannot overwrite.

    In order to gain administrative privileges, the user is prompted for his/her admin password. iTunes would need to get admin authorization to take advantage of admin privileges. Mac OS X does have a problem for those applications which demand admin privileges to be installed. There’s nothing to stop the privileged installer from setting the setuid bit on the installed app, so that it always gains root privileges when it is launched. I dislike any appliction which cannot be installed using a simple drag-and-drop for precisely this reason.

    So you do need to run as admin/root to do massive amounts of damage, but it is not impossible for an installer to bestow those privileges on the app. A user with a regular account would simply be unable to install the software this way.

    Not enough space to detail all the permissions on a typical Mac OS X installation, but as an example consider that even an administrator cannot modify the contents of /System/Library.

    Hope this helps

  5. Peter Torr says:

    Thanks for the comments so far.


    Sounds like you are talking about NGSCB (Palladium).


    Yes, I used to be the Program Manager for JScript, but I disable pretty much all of IE’s features by default.

    David #1:

    It’s not so much tin-foil-hattery that compels me to disable script; it’s a matter of principle. Most people on the web abuse script (and HTML for that matter) to do things they were not intended to do. Also as soon as you turn on script you get bombarded with all manner of advertisements, etc. (and no, a pop-up blocker won’t stop them all).

    David #2:

    Thanks for the comment. It seems we disagree on what "massive amounts of damage" are — I would consider deleting all of my documents, e-mails, pictures, music, etc. and then flooding the network with millions of packets to be "massive amounts of damage," and doing that does not require admin privileges. (None of the recent worms _need_ admin privileges to do what they do, including Blaster, Slammer, MyDoom, NetSky, etc. Now they may have been poorly written such that the fail without admin permissions, but that’s just a bug in the worm).

    Also, how do you patch a security hole in /System/Library?

  6. David Buxton says:

    Yes, your definition of "massive amounts of damage" is certainly pretty damaging. And a Mac app launched by a local user could do all that. But, without being explicitly authorized to run with admin privileges, it couldn’t delete the documents belonging to another user. You are right in that Mac OS X does not have the solution to all these problems. There have been security updates provided by Apple to address the problem of apps having setuid privs when they shouldn’t, so it continues to be a problem requiring vigilance.

    I would point to two areas where the Macintosh shows a more responsible approach to computer security (compared to Windows).

    The first is the absence of a desire to provide hooks in the operating system and its key applications for Internet control. I see why Microsoft likes the idea, but it seems obvious to me that it is a very dangerous idea. Caution is required when implementing such hooks, more caution than Microsoft has shown.

    The second is a more thorough separation of administrator and regular user privileges. In Mac OS X this manifests itself as (mostly) defensive permissions on the filesystem and a security framework that puts the onus on the user to grant escalated privileges to an application, rather than the system trusting that an application needs the privileges it wants. Sensible defaults can greatly lessen the impact of potential problems.

    I’m sure you can explain how this works for Windows, of which I have very little experience.

    As for patching files in /System/Library: you cannot touch that folder using the Finder, but any application which has been authorized can gain root privileges and mess with that stuff. From the command line, an admin user can use `sudo` to run any app with root privileges. Third-party software which places itself in the /System directory is a real pain for this reason, and Apple discourages developers using /System.

    What do you reckon?

  7. grey says:

    The MS permission mentality is all over the board. Great the day will be when the next spyware package bitches at me for needing Administrative privs before it can be installed, and Outlook doesn’t bitch at me because the user is not administrator when running it for the first time on a 2k+ box. Solve those two problems first (or even the first one) and then start comparing Apples to MS installers.

    Give me a friggin useful ‘su’ (ideally with an -l flag maybe) command so that I’m not dealing with gaping security holes like sanur in order to script up something functional with runas. Please explain to me why Exchange 2k3 no longer allows administrator to view users’ mailboxes by default, but administrator is still the default user who can set up such permissions under system manager; hell tell me why I need to edit the registry before I can even _see_ a frigging security tab in Exchange2k3’s system manager.

    Apple is able to leverage the history of unix fs permissions to its advantage, and this trickles into its installer mechanism. Apple didn’t add a feature like ActiveX to its browser which allows code to be executed when browsings a friggin website, they also didn’t start the trend of running an exectuable from an email message. While the granularity of permissions Apple was able to use is sparse (even when using chflags or something) the fact that it had them with OSX from the getgo, vs MS having to adhere to backwards compatibility with FAT32 helps a bit. Same goes for the concepts of administrator being new with NT/2k+ relative to 9x. You have all this software which needs to install on NT based systems and 9x based systems and you lose. Apple has a similar problem with OS9 relative to OSX, but much less so. OSX they’ve been able to start off on a much better foot.

Skip to main content