Post reaches Hacker News frontpage
3 Sep 20 2:42 PM · 3d ago · 1 article · 1 post · 2 sources · development 3 of 3
The sandboxing guide reaches Hacker News frontpage with 53 points and 6 comments, expanding its visibility among tech developers.
Emilua developer (author) Blog author, sandboxing implementer
The whole story articlesposts the bright band is this development · numbered dots are the others · click one to jump
Reported in the same hours no headline names this development itself — these 1 claim were published in its stretch
-
1 outlet Software Sandboxing: The Basics
first by HN Frontpage, 3d ago
What people said 24 voices · best of 34 · verbatim
-
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.
-
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.
-
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.
-
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…
-
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…
-
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.
-
> 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…
-
> 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…
-
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…
-
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…
-
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…
-
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…
-
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…
-
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'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.
-
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.
-
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.
-
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.
-
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.
-
Well, writing software that would use them would create pressure for users to enable them.
-
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…
All 3 developments of Emilua developer publishes software sandboxing guide →
Hacker NewsLobstersNewswires