Use OS X sandbox to limit installations to the current source tree.

[alloy]

Note: Updated original ticket to show TODOs instead.

The current version of the bin wrapper can be found here.

Script TODOs

• Make using xcodebuild for resources bundles work. Currently this fails
  because it wants to use FSEvents on the root path /. (See comment below.)
• Check if we should be importing any other default profiles. E.g. bsd.sb.
• Use literal paths where possible, instead of regex.
• How are we going to handle allowing processes like git, svn, and hg
  to work when they might be somewhere in a non-standard prefix?
• Can we scope rules like file-read/file-write to specific processes? E.g.
  limit git to only those directories where any git operations should be
  performed, while allowing xcodebuild access to more directories.
• Limit the scope of the rules where possible. E.g. network-outbound and
  access to the user home directory.
• Installing docs with appledoc requires Apple Events and iirc, from a
  CoreInt episode, this is damn hard to do in a sandbox environment.
• Allow the user to add custom rules to the sandbox profile from the Podfile?

Integration Test TODOs

• Add test that ensures FS modifications outside the project source tree are disallowed.
• Add test that ensures using unsanctioned processes is disallowed.
• At least in a VM, ensure that [sudo] rm -rf / does not work.

[iamleeg]

If I understand correctly (and please do flame if I don't), when I do this:

$ cd ~/Projects/MyAwesomeFartApp
$ vi PodFile
$ pod install

the 'pod' process should be able to write to MyAwesomeFartApp and all subfolders, but not anywhere else in the filesystem.

This is tricky™. Because 'pod' isn't a Cocoa app, you can't sign it with sandboxing entitlements (and the Mac App sandbox wouldn't support this case anyway). So you have to look lower level, to the seatbelt access control system.

…the problem here is that there are only a handful of default profiles for seatbelt, none of which fit this use case. While you can write custom profiles, it's an undocumented format that Apple warn is subject to change at any time and should not be used. I'd consider that sufficient warning to stay away from doing it.

…oh, you're still reading? :-D OK, so you want to look at the scripts in /usr/share/sandbox on your Mac: you'll see that these are Scheme programs that are simple to understand. Your pod script would be a wrapper that:

• gets the project folder
• constructs a Scheme script with appropriate controls
• calls /usr/bin/sandbox-exec -p "${SCHEME_SCRIPT}" /path/to/realpod.rb

Though as I say this is fragile.

[alloy]

You understood it perfectly. Thanks a lot for your time.

Regarding the warning about this being an undocumented format, we will take it very serious. Luckily we have the advantage that we don’t have to run in the sandbox. So we can enable it by default, but if a OS update would suddenly change the format people can still run the tool with --no-sandbox. Besides, we already use the undocumented xcodeproj format, so we’re already off the pure path ;)

Ok, that looks pretty simple, I’m looking forward to banging my head over this for a couple of evenings :D

[alloy]

Ok, I couldn’t stop myself from playing with this last night, so I now have a somewhat working version.

With this profile I am able to run normal installations and the example building on the OS X Travis workers works as expected.

However, a current issue is with, for instance, the HockeySDK spec, which uses xcodebuild to create a resource bundle. So while normal project building with xcodebuild does work, it seems to fail for resource bundles, because for some reason it want’s to get notified of FS events for the root path / and I don’t want to just allow reads to the full filesystem:

Installing HockeySDK (3.0.0)
Generating Pods project
2013-04-06 12:15 xcodebuild[51221] (CarbonCore.framework) FSEventStreamCreate: _FSEventStreamCreate: ERROR: watch_path() failed for '/'
2013-04-06 12:15 xcodebuild[51221] (CarbonCore.framework) FSEventStreamCopyPathsBeingWatched(): failed assertion 'streamRef != NULL'

sh: line 1: 51221 Segmentation fault: 11  xcodebuild -project HockeySDK.xcodeproj -target HockeySDKResources CONFIGURATION_BUILD_DIR=../Resources 2>&1 > /dev/null
[!] The post install hook of HockeySDK (3.0.0) is not compatible with this version of CocoaPods.

/var/log/system.log:

Apr  6 12:15:02 Khaos kernel[0]: Sandbox: ruby(51122) deny file-read-data /
Apr  6 12:15:02 Khaos kernel[0]: Sandbox: xcodebuild(51221) deny file-read-data /
Apr  6 12:15:02 Khaos.local ReportCrash[51222]: DebugSymbols was unable to start a spotlight query: spotlight is not responding or disabled.
Apr  6 12:15:03 Khaos.local ReportCrash[51222]: failed looking up LS service ( scCreateSystemService returned MACH_PORT_NULL, called from SetupCoreApplicationServicesCommunicationPort, so using client-side NULL calls.
Apr  6 12:15:03 Khaos.local ReportCrash[51222]: LaunchServices/5123589: Unable to lookup coreservices session port for session 0x186a0 uid=0 euid=0
Apr  6 12:15:03 Khaos.local ReportCrash[51222]: failed looking up LS service ( scCreateSystemService returned MACH_PORT_NULL, called from SetupCoreApplicationServicesCommunicationPort, so using client-side NULL calls.
Apr  6 12:15:03 Khaos.local ReportCrash[51222]: LaunchServices/5123589: Unable to lookup coreservices session port for session 0x186a0 uid=0 euid=0
Apr  6 12:15:03 Khaos.local ReportCrash[51222]: failed looking up LS service ( scCreateSystemService returned MACH_PORT_NULL, called from SetupCoreApplicationServicesCommunicationPort, so using client-side NULL calls.
Apr  6 12:15:03 Khaos.local ReportCrash[51222]: LaunchServices/5123589: Unable to lookup coreservices session port for session 0x186a0 uid=0 euid=0
Apr  6 12:15:03 Khaos.local ReportCrash[51222]: failed looking up LS service ( scCreateSystemService returned MACH_PORT_NULL, called from SetupCoreApplicationServicesCommunicationPort, so using client-side NULL calls.
Apr  6 12:15:03 Khaos.local ReportCrash[51222]: LaunchServices/5123589: Unable to lookup coreservices session port for session 0x186a0 uid=0 euid=0
Apr  6 12:15:03 Khaos.local ReportCrash[51222]: failed looking up LS service ( scCreateSystemService returned MACH_PORT_NULL, called from SetupCoreApplicationServicesCommunicationPort, so using client-side NULL calls.
Apr  6 12:15:03 Khaos.local ReportCrash[51222]: LaunchServices/5123589: Unable to lookup coreservices session port for session 0x186a0 uid=0 euid=0
Apr  6 12:15:03 Khaos.local ReportCrash[51222]: Saved crash report for xcodebuild[51221] version ??? to /Library/Logs/DiagnosticReports/xcodebuild_2013-04-06-121503_Khaos.crash

[xslim]

Just tried sandbox-pod install
The only deny I get in system.log is

May 24 01:06:26 tkalapun-air kernel[0]: Sandbox: ruby(5450) deny file-read-data /Users

Oh, BTW, I have RVM installed…

[alloy]

@xslim Thanks. I’ve seen that one too. I’m thinking it might have to do with finding the user's HOME dir, but for now I haven’t seen any failures because of it, so I’m inclined to leave it be.

[nikolaykasyanov]

Having an issue with 0.20.1 and sandbox-pod:

$ sandbox-pod --version
/Library/Ruby/Gems/1.8/gems/cocoapods-0.20.1/bin/pod:14:in `require': no such file to load -- cocoapods (LoadError)
from /Library/Ruby/Gems/1.8/gems/cocoapods-0.20.1/bin/pod:14

I'm using default OS X's ruby and once I used sudo gem update --system if it matters.

And there's nothing special in /var/log/system.log after that error.

Good old pod command works fine.

[alloy]

@Corristo Thanks! Fixed in 4ce6e4a. I’ll probably release that tomorrow.

[alloy]

@Corristo Just released 0.20.2, please try if that fixes your issues.

[nikolaykasyanov]

@alloy works like a charm, thanks

[CocoaPodsBot]

Issue has been confirmed by @neonichu

[alloy]

Superseded by #2848.