Adium

Opened 7 years ago

Last modified 7 years ago

#16160 new enhancement

Sandboxing: What else to do

Reported by: sphynx Owned by:
Milestone: Component: Adium Core
Version: Severity: normal
Keywords: Cc:
Patch Status:

Description (last modified by Thijs Alkemade)

6fd7dfef3669 enabled sandboxing on Adium.app. Even though the Mac App Store might not be something we can do, I still think we should do this to improve the security of our users.

Sandbox violations

The only violation left that I know of is deeply in the Address Book API, probably an Apple bug.

Privilege separation

We could improve the security of the sandbox by splitting Adium up into a couple of XPC services.

We currently request:

  • Network server/client:
    • All protocols: libpurple/Twitter/Bonjour.
    • Sparkle update checking
    • xtra installation
    • Growl

We could separate libpurple/Twitter/Bonjour into separate XPC services that have only this privilege (maybe with user selected file access, depending on how file transfers work). Benefits would be a lot of extra security and stability, as anything that crashes libpurple will not crash Adium and it forbids libpurple from reading any file it shouldn't. However, it would require a lot of communication between these parts and the core (all libpurple structs would need to be serialized/unserialized all the time).

  • User selected file read/write
    • File transfers
  • Download folder read/write
    • Automatically accepting file transfers

Both of these I'm not sure of. The core handles the Save Dialog that pops up, but I'm not sure where the file is actually opened (libpurple or Adium itself).

  • Address Book access
    • Linking contacts

This could probably be made into a separate service quite easily.

  • Printing
    • We can print the message view. For some reason.

Change History (3)

comment:1 Changed 7 years ago by Thijs Alkemade

Also, just noticed this now:

The AIApplescriptRunner XPC service wasn't sandboxed when I tested it. com.apple.security.temporary-exception.apple-events can, for now, still request Applescript messaging permissions, but it needs to enumerate all apps that it wants to message. We can easily do that for those we need internally (just iTunes and browsers?), but there might be a large number of custom scripts out there that people have to communicate with all sorts of apps.

I really hope Apple introduces a non-temporary solution for Applescripts...

comment:2 Changed 7 years ago by Thijs Alkemade

Description: modified (diff)

comment:3 Changed 7 years ago by Thijs Alkemade

NSUserAppleScriptTask is a new API in 10.8 that allows apps to run AppleScripts from ~/Library/Application Scripts/<code-signing-id>. These run outside the app's sandbox, but a sandboxed application only has read access to this directory.

This should allow us to continue to use the applescripts we use now, with the only caveat that users need to install them manually. But I think scripting is quite a power-user feature that this would not be much of a problem.

Note: See TracTickets for help on using tickets.