| Hi, Thanks for those ideas - some early comments on those below: > symbols could just be all prefixed IMO, this wouldn't be conceptually different from how it works now - i.e. calling function through a C++ object. IOW: code using sandboxing "printf" would have to be changed to use "_sanbdoxed_printf" somehow (via code or linker tricks). Unless you mean something different here? > File descriptors could be indicated with an annotation or simple function call. Similarly to the problem above - it's probably in line with how it works now. It can definitely be simplified (even with a simple annotation "somewhere"), but again, that wouldn't probably solve the problem of having drop-in library replacement IMO? > use a special allocator for anything that's going to be passed to the sandbox, and putting that memory onto an exchange heap ala Singularity. Yes, that's something we're thinking about, mainly for performance reasons. As you certainly know, it will be more complex than simply having malloc()/calloc() (and friends) operating on a shared mmap(), as memory referenced can also include stack/bss/rodata/direct-mmap etc. etc. These are all good ideas! Thanks for sharing them - in case you'd like to comment on them more, I'd like to invite you to do that on the project's mailing list. PS: It might also be here that you might be thinking about something slightly else. I.e. moving all annotations wrt memory/file-descriptors into some middle layer, and then exposing identical-to-the-original library API. This is probably possible, even now, with some extern "C" magic, though there are no examples or tooling on how to do that yet. |
I mean, linker tricks à la LD_PRELOAD, DYLD_INSERT_LIBRARIES are a lot less work than rewriting code. They don't even require a recompile most of the time.
I think this does however bring up an interesting point: it seems like this library is trying to solve a somewhat different subset of the sandboxing, which is the question of "how do I maintain separation if I'm writing code on both sides of the sandbox", whereas sandboxing can also include "how do I stop this arbitrary binary from doing malicious things". It seems to me that the latter usually ends up requiring support in the kernel or linker but no cooperation from the sandboxed process itself, while the former requires adoption new API (for example, macOS's XPC).