Comment by jparishy | Hacker News Reader

Comment by jparishy | Hacker News Reader

Parent Full thread

That's one way to do it, sure. In this case I had the problem of having to use a Mac for a build server, though.

I did a few things to get this running:

- The application server and build server are separate, with access control to the build server controlled by an API key that I can revoke should anyone gain access to it.

- The process that compiles and runs your code is an unprivileged user.

- All import statements are disabled in user submitted code

- Foundation is imported selectively with only a few classes allowed to be used by submitted code (namely, the NSString, NSArray, NSDictionary, etc APIs)

- Code is checked for a list of blacklisted APIs before hitting the compiler

- The execution of your code has a timeout of a few seconds, and the process will be killed should it take any longer.

I looked into more advanced techniques for sandboxing but couldn't find anything on OS X that was feasible. Happy to be schooled on security though, if you know better than I do :)

You can execute the process under sandbox-exec to take advantage of OS X kernel-level sandboxing. You'll need to write your own profile file that allows/denys what you want. There are plenty of examples of these .sb profile files under /System/Library. More: https://developer.apple.com/library/mac/documentation/Darwin...

Excellent! Thank you for pointing me to this!

Good tip. Another suggestion would be to use chroot :)

That said, the best, most foolproof way of doing this really comes down to using OS X to virtualize OS X.

Or you could try cross-compiling. It seems to work here: https://github.com/swift-x/tools (which looks interesting...)

It's possible that by the end of this week, maybe next, it will be very easy indeed to compile and/or run Swift on Linux from Linux, at which point you could try LXC or a million other ways to virtualize.

Thanks for the tips! I'd love to move to LXC should an appropriate/feasible compiling solution become available :)

This mechanism has been deprecated by Apple. In the header file they point out that one should use the OS X sandboxing instead which works with plists instead and can be controlled with less flexibility.

Calling sandbox_init from inside your app has been deprecated in favor of the App Sandbox mechanism, but I don't see any indication that sandbox-exec is deprecated.

Just deployed a new script runner backed by sandbox-exec! Thanks again for the tip!

Reply on news.ycombinator.com