Application Sandboxing Overview

Application sandboxing restricts an application’s access to only system resources, including the file system, for which it’s explicitly given access. A sandboxed application is given a code signature to prevent tampering, and a list of system resources it’s allowed to access. This list of system resources is called its entitlements—see Specifying Entitlements. Figure 3-1 compares access levels for an application with sandboxing and an application without sandboxing.

Prior to application sandboxing, loading arbitrary third-party code had full system access, presenting a potential security issue. There are three ways to combat this:

• Restrict the host application’s entitlements to the basic necessities.

• Force loaded code, such as a plug-in, to operate with no more entitlements than the host (privilege inheritance).

• Design the host application to take advantage of OS-mediated XPC Services, a type of interprocess communication (IPC), which are handled securely at the system level.

  An XPC Service is a lightweight “helper tool” process that can be spawned with its own entitlements to perform work on behalf of an application. Having its own entitlements is called privilege separation and dramatically reduces the possible harm from a malicious attack in the case of code injection or the like.

FxPlug plug-ins conveniently bundle the necessary components for a traditional XPC Service, making it easier for developers to adopt. For most plug-in developers who do not need entitlements beyond what’s provided by Motion and Final Cut Pro, migrating existing plug-ins is a simple process that consists mostly of adding Xcode targets and plist entities. For developers who want to use extra entitlements, such as network access, address book access, or the built-in camera, migrating code into an XPC Service can help.

When an FxPlug plug-in needs to communicate with its out-of-process XPC Service, developers can employ the new FxPrincipalAPI, which returns a proxy object.

This proxy object accepts method calls, relays them across processes, and returns the results. It’s fast, asynchronous, and less complicated than setting up your own XPC Service. The proxy object knows what methods can be used by way of a developer-established protocol, which is linked to by both the in-host component (the Embedded Principal) and the out-of-process XPC Service (the Service Principal—see Embedded Principal and Service Principal Communication), as shown in Figure 3-2.

All three components (Embedded Principal, Service Principal, and Protocol) are combined into a single bundle, an application bundle. This application bundle is the new FxPlug 3.0 plug-in structure—see Creating a New FxPlug Application Bundle and Converting Old FxPlug Plug-ins to New FxPlug Plug-ins. Multiple filters can be bundled into a single application and use the same Service Principal. Developers can take advantage of this new structure and write an application that users see when they double-click the plug-in, and plug-ins no longer have to live in a special folder in the system.

Specifying Entitlements

Refer to Entitlement Key Reference for information on how to specify entitlements for your FxPlug plug-ins.

Plug-in Discovery

Plug-in discovery transpires via PlugInKit, a new OS X v10.9 system component. Launch Services automatically registers your plug-in with PlugInKit when the user copies the file to their system the first time. When Motion or Final Cut Pro runs, it queries PlugInKit for all FxPlug plug-ins and loads any it finds. Your plug-in must have an additional entry in its plist file for PlugInKit-specific data.

For plug-ins using dynamic registration, the +sharedInstance method is not called when loaded from PlugInKit; instead, the -init method is called.

defaults write <host-application> <path-type> -array <paths>

Managing Plug-in XPC Lifetime

An XPC service is expected to keep minimal state so the OS may start and stop it as needed without disrupting communication between the XPC and the host. As such, the OS can kill the XPC if, for example, system memory is getting low. The host application is expected to restart the XPC whenever it needs to communicate with it.

For a typical application that owns its XPC, restarting the XPC is not usually a problem. However, because an FxPlug’s XPC belongs to the plug-in, the host application is not always aware that it’s trying to communicate with the XPC.

Starting with Final Cut Pro X 10.3 and Motion 5.3, the host application ensures the XPC is running before making any calls to the plug-in’s embedded code. There are still times, however, when the plug-in may be called directly by the OS to perform actions and may need to communicate with its XPC. For example, if a plug-in has a custom view to display a custom parameter, the OS directly calls the view’s -drawRect: method. In cases like this, the plug-in should call the [-FxCustomParameterActionAPI startAction:] method before performing any communication with the XPC, and then call [-FxCustomParameterActionAPI endAction:] when it is finished.

As a rule, whenever a plug-in is going to communicate with its XPC, and it wasn’t directly called by the host application, the plug-in needs to call -startAction:/-endAction:.