Objective-C Plugin Architecture Security (Mac, not iPhone)

Perhaps I wrote a plugin for a Cocoa application (Mac, not iPhone).

The general approach is to make each plugin a package, and then insert the package into the main application. I am concerned about the security implications for this, as the package will have full access to the Objective-C runtime. I am particularly concerned about a plugin having access to a code that processes registration and serial keys.

The other plugin system we are considering is based on distributed notifications. In principle, each plugin will be a separate process, and they will only communicate through distributed notifications.

Is there a way to reliably download packages (like a sandbox)? If not, do you see any problems using distributed notifications? Are there any other plugin architectures that would be better?

+7
plugins objective-c architecture cocoa
source share
1 answer

Yes, OS X has sandbox support at every process level. The only third-party open source client that I know of is Chrome . You can also explore a shell such as the Native Client .

However, it makes no sense to try connecting security plugins for security reasons unless you download unreliable plugins or content over the network (i.e. a web browser). If someone wants to hack your application locally, he can just use a debugger, DTrace, etc.

Which IPC mechanism you use between your application and the plugin processes really depends on the type of communication you have. Intermachine Distributed Objects (I assume that what you wanted to write), of course, is not a bad choice for most purposes, but you would not want to send video on it. You can check out CoreIPC , which underdeveloped WebKit2 uses; It works through Mach ports.

+2
source share

All Articles