31–40 of 72 posts
If you can afford to sacrifice that much performance just to run some potentially unsafe code, then you can probably afford to not be writing Rust in the first place and instead use a garbage-collected language.
Rather design the application from the start to use multiple processes, OS IPC and actual OS sandboxing APIs. Pseudo sandboxing on the fly is an old idea and with its own issues, as proven by classical UNIX approach to launching daemons.
What are the sandboxing APIs you’d recommend on Linux, Mac, & Windows? I haven’t been able to find any comprehensive references online.
Windows: https://chromium.googlesource.com/chromium/src/+/main/docs/d...
Linux: https://chromium.googlesource.com/chromium/src/+/main/sandbo...
OS X: https://chromium.googlesource.com/chromium/src/+/main/sandbo...
With the caveat that I wouldn't necessairly assume this is the cutting edge at this point, and there might be other resources to invest in for server-side sandboxing involving containers or hypervisors, and that I've only actually engaged with the Windows APIs based on that reading.
I wrote `firehazard` ( https://docs.rs/firehazard/ , https://github.com/MaulingMonkey/firehazard/tree/master/exam... ) to experiment with wrapping the Windows APIs, document edge cases, etc. - although if the long list of warnings in the readme doesn't scare you away, it'll hopefully at least confirm I hesitate to recommend my own code ;)
Earlier quoted context omitted.
macOS provides native sandboxing; you can use capabilities at the app level[1] or the sandbox-exec CLI to wrap an existing tool. For Windows, you probably want WSB[2] or AppContainer isolation[3]. For Linux, the low-level primitives for sandboxing are seccomp and namespaces. You can use tools like Firejail and bubblewrap to wrap individual tool invocations, similar to sandbox-exec on macOS. [1]: https://developer.app…
Linux also has Landlock now. macOS sandboxing is notoriously under-documented, has sharp edges, and is nowhere near as expressive as Linux sandboxing.
Earlier quoted context omitted.
macOS provides native sandboxing; you can use capabilities at the app level[1] or the sandbox-exec CLI to wrap an existing tool. For Windows, you probably want WSB[2] or AppContainer isolation[3]. For Linux, the low-level primitives for sandboxing are seccomp and namespaces. You can use tools like Firejail and bubblewrap to wrap individual tool invocations, similar to sandbox-exec on macOS. [1]: https://developer.app…
Linux also has Landlock now. macOS sandboxing is notoriously under-documented, has sharp edges, and is nowhere near as expressive as Linux sandboxing.
Agreed about macOS's sandboxing being under-documented.
Earlier quoted context omitted.
Well, you can close all file descriptors (except the pipe used for sending the return value back to the parent), re-mmap all files with MAP_PRIVATE, and then use SECCOMP_SET_MODE_STRICT to isolate the child process. But at that point, what are you even doing? Probably nothing useful. If there were a Quick Fix for safety, we'd probably have discovered it by now.
> use SECCOMP_SET_MODE_STRICT to isolate the child process. But at that > point, what are you even doing? Probably nothing useful. The classic example of a fully-seccomp'd subprocess is decoding / decompression. If you want to execute ffmpeg on untrusted user input then seccomp is a sandbox that allows full-power SIMD, and the code has no reason to perform syscalls other than read/write to its input/output stream. On…
Yes. I've run JPEG 2000 decoders in a subprocess for that reason.
https://hacks.mozilla.org/2020/02/securing-firefox-with-weba...
Firefox employs processes for sandboxing but for small components they are not worth the overhead. For those they employed this curious idea: first compile the potentially unsafe code to wasm (any other VM would work), then compile the wasm code to C (using the wasm2c tool). Then use this new C source normally in your program.
All UB in the original code becomes logical bugs in the wasm, that can output incorrect values but not corrupt memory or do things that UB can do. Firefox does this to encapsulate C code, but it can be done with Rust too
Earlier quoted context omitted.
Well, you can close all file descriptors (except the pipe used for sending the return value back to the parent), re-mmap all files with MAP_PRIVATE, and then use SECCOMP_SET_MODE_STRICT to isolate the child process. But at that point, what are you even doing? Probably nothing useful. If there were a Quick Fix for safety, we'd probably have discovered it by now.
> use SECCOMP_SET_MODE_STRICT to isolate the child process. But at that > point, what are you even doing? Probably nothing useful. The classic example of a fully-seccomp'd subprocess is decoding / decompression. If you want to execute ffmpeg on untrusted user input then seccomp is a sandbox that allows full-power SIMD, and the code has no reason to perform syscalls other than read/write to its input/output stream. On…
This is cool from a theoretical perspective, but `fork()` can be prohibitively expensive, at least on the hot path. This is a cool tool that should be used with care.
Which pretty much makes this whole thing pointless since a lot of unsafe code exists purely for performance reasons.
I'm sure there's still value in this project, but I'm not sure I'm versed enough in Rust to know what that is.