Emilua developer publishes software sandboxing guide
Technical essay on implementing sandboxing practices circulates across developer communities.
What to know
- Developer shares practical sandboxing guidance drawing from real implementation experience with Emilua.
- Post argues traditional UNIX permission tools are inadequate for modern sandboxing; OS-level interfaces like Capsicum and Seccomp are better practices.
- Content gains traction across multiple developer communities (Lobsters, Hacker News) within days of circulation.
Emilua developer (author) Blog author, sandboxing implementer
How it unfolded 3 developments, newest first · click a bar or a number to jump articlesposts
-
3
Post reaches Hacker News frontpage
The sandboxing guide reaches Hacker News frontpage with 53 points and 6 comments, expanding its visibility among tech developers.
-
I really wonder why OpenBSD's pledge and unveil are missing. They are prime examples for working sandboxing including small applications like Chromium and Firefox.
2 more of the top 3 · 34 posts in this stretch
-
Capsicum may not have caught on, but capabilities are having a bit of a comeback right now. WASI, the wasm system interface, started with a classic UNIX-style API in 0.1 but now pivoted hard and is fully leaning into capabilities. And it makes sense there too, because wasm itself is fully free of ambient authority. You don't need any sandboxing…
-
The code to implement Chromium’s sandboxing model with Capsicum was an order of magnitude less than that for *any* other platform. The patches were rejected because Google does not accept *any* patches to support targets that Google does not ship Chrome for. Google engineers implemented Capsicum for Linux. The patches were rejected for NIH reasons.
-
-
2
Sandboxing post gains traction on Lobsters
The Emilua sandboxing guide is shared on Lobsters and reaches 28 points with 5 comments, indicating developer community interest.
“Diving into the territory of software sandboxing is diving into mostly uncharted territory. The necessary pieces to implement good sandboxing in your software are scattered all-around.”
— Emilua developer, Blog author · source - 2 days quiet
-
1
Wanix project demonstrates WASM-native Unix sandboxing
A complementary sandboxing project, Wanix, becomes visible in developer circles. It runs Wasm and x86 programs entirely sandboxed in the browser using Plan 9-inspired architecture, providing an alternative sandboxing implementation.
-
background
Developer publishes software sandboxing guide — A technical blog post on software sandboxing basics was published, drawing on the author's experience implementing sandboxing support for Emilua. The post covers foundational concepts, OS interfaces for sandboxing, and limitations of traditional UNIX approaches.
What people are saying 21 voices from 1 site · best of 34 · verbatim
- Sep 21
-
The thing is, I *want* people to restructure their program to think about security. I like that Capsicum works best when developers are aware of it and give some thought in their program to how capabilities should flow. I think that this thinking is necessary to have secure ecosystems in the long term. In particular, when security frameworks are…
-
No it seems like it’s all about writing software that’s less likely to host a weird machine than about user choice and supervision of programs. Which is different from a program that is ready to be sandboxed but the sandbox is external to it. That seems to be the model that allows user interaction.
-
OK now take your usual program that opens sockets and files in a bunch of places using the usual suspects (e.g. just `open` and not `openat`), and maybe does some DNS requests somewhere deep down. To the best of my knowledge, apart from any messy `LD_PRELOAD` hacks (because let's face it, that's what they are), the only way you can get such a…
-
When last looked (_many_ years ago), the systems like pledge, capsicum, etc were all built around applications requesting everything up front, and at the time there was no support from the rest of the OS to support extending the sandbox later: e.g the open dialogs could not extend the sandbox, etc. My assumption was that because these were…
-
I think what David is saying is that he was using ld_preload for an already compiled binaries (not sure if for the main binary or system libraries) - eg not just no restructuring but no recombination rather.
-
> because the alternative (requiring container runtimes to run as root and stopping programs like chrome from effectively self-sandboxing) is worse There's another alternative: only allow unprivileged user namespaces to trusted tools such as Docker, Firefox, and Chrome. There's no reason to expose this attack surface for untrusted execution paths…
-
The FreeBSD base system has a bunch of capsicum code in it. I know the last big release added a bunch more utilities with capsicum. So it is one of those slow burns, but it is still being used. I think the big thing that prevented it from catching on is it never really left the FreeBSD platform. Linux had a port or two, but everyone was afraid of…
-
You don't need to `LD_PRELOAD` if you don't want to run unmodified binaries. I've also just written a five-line replacement for `open` in the main program and had the whole thing work nicely with `cap_enter` near the start. You *can* completely refactor your program to follow an explicit capability model with Capsicum. I'd argue that it's good…
-
That is true, however I think that ship has sailed. Most distros, including debian, Arch, NixOS, Fedora, openSUSE and Alpine now allow this by default. Several of them had previously disabled unprivileged user namespace creation because of those security concerns, but switched this default in recent years because the alternative (requiring…
-
> I think you then can't create private mounts and virtual network interfaces Yes, by itself, you can't. However, you also can't do that by mapping yourself to root. You'll still be in the mount and network namespaces that you inherited, which belong to the *outside* user namespace, in which you are (I'm assuming) not root. You will see the…
-
I'm reading about it. I think if you don't map yourself to root inside the namespace it's more similar to just doing setuid / setgid. I think you then can't create private mounts and virtual network interfaces, so such user still has access to the original filesystem and network as normal nobody user would. I might be wrong.
-
You don’t need to restructure the whole program. I use Capsicum to sandbox existing code with a little LD_PRELOAD shim that replaces open with a table lookup and an openat system call. You *can* restructure your program to make authority explicit and that’s a feature if you want to actually be able to reason about what your security model is.
-
Good point ... also the point of @5d22b. But from what I understand using --unshare to run a script that I don't trust gives creates a fake "root in a box", but that root still gets access to risky kernel parts / code paths. So this being enabled is bad, and using this just makes it worse. (so I will be removing this whole feature) // sorry for…
-
Well, writing software that would use them would create pressure for users to enable them.
-
I don't think it's even the use of e.g. user namespaces that increases the attack surface, but their mere presence. As in, whether ryelang uses them or not is not the issue, but whether the running kernel is configured to allow unprivileged user namespace creation at all.
-
This was a very good read, but I'm not super ecstatic about it because I was implementing the --unshare flag in ryelang for past week. And now if I understand the: > Another related concern here is to not design APIs that backfire by exponentially increasing the kernel attack surface. ... then this is basically introducing a big liability, not…
-
the fact it hasn't caught on is a hint that maybe its design isn't ideal? as a clueless noob developer, if someone told me to use selinux/apparmor/capsicum to sandbox my program, it sounds daunting already without even having to start. developer experience is crucial if you're trying to convince developers to sandbox their programs. Pledge/unveil…
- Sep 20
-
I tried to use it, but I couldn't even figure out how to make it work with sqlite in Go. It's far easier to use landlock or pledge ime.
-
It also puzzles me. I'll try to answer below, but we'll never know the answer so my guess is as good as any. For outsiders, BSD is a confusing ecosystem. You have FreeBSD, NetBSD, OpenBSD, and DragonFly BSD. For outsiders, there's no criteria to favor one over the other, nor any criteria to adhere to some "official" flavor. If Chrome (or Firefox)…
-
For the simple reason that using Capsicum requires you to not only restructure your program (= by opening file descriptors ahead of time and using e.g. `openat`), but also by using FreeBSD specific functions provided by libcasper. Basically with e.g. Landlock and unveil, you write maybe 10-20 lines and you're good to go. With Capsicum you have to…
-
When capsicum came out, I remember reading the paper and thinking”yes, this is the way!”. Unfortunately, it never caught on. I don’t understand why not.