MacPorts and sandboxing

[Jordan K. Hubbard]

On Sep 27, 2012, at 1:09 PM, Clemens Lang <cal at macports.org> wrote:

> chroot certainly is a way to solve this problem, but I think it's too
> heavyweight and slow for our needs.

And, as Joshua already pointed out, it suffers from a number of flaws.  chroot(8) on OS X has become essentially deprecated due to all the various daemons and filesystems that need to be instantiated / mounted in it in order to provide any  (and in the former case, I don't think successfully as they were never designed for it).

> We could fix the way trace mode worked before, i.e., using an "overlay
> filesystem" using DYLD_INSERT_LIBRARIES (the eqivalent to Linux'
> LD_PRELOAD). Wrapping filesystem-related syscalls is a way to implement
> sandboxing. It's not impossible to escape from this poor man's sandbox,
> though. The downside of this method is the number of syscalls and
> userland-side configuration we need to support (32bit vs. 64bit
> syscalls, inodes, etc.).

I don't think the goal of trace mode and the overlay was ever truly meant to represent a sandbox, I just thought sandboxing might kill two birds with one stone if we could somehow make it work.  I think that a working trace mode would still serve the primary purpose of making the MacPorts build process more verifiable / reproducible / safer on an arbitrary (customer) build machine and is largely orthogonal to the goal of sandboxing the software it produces, which is actually a much more interesting / tractable goal since the software is going to get a lot more runtime, particularly if the user got it pre-packaged.

> That being said, I already have most of the work done locally. I haven't
> commited this yet because I'm still hunting a bug where the socket
> connection to port(1) controlling the sandbox is lost (and the next call
> to send(2) fails with ENOTSOCK).

Why not check it on on a branch?  Maybe someone else can help you debug it! :)

- Jordan