21–30 of 30 posts
There were some rough edges back then, but it had been my go-to tool to run user-provided code in isolation.
it'd be interesting to see a comparison of these -- the building blocks are (mostly) the same, but the interfaces differ in interesting ways: - nsjail - firejail - bubblewrap - runc etc.
A parent comment mentions ebpf syscall interception, many end up combining gvisor and nsjail and seccomp.
it'd be interesting to see a comparison of these -- the building blocks are (mostly) the same, but the interfaces differ in interesting ways: - nsjail - firejail - bubblewrap - runc etc.
A few decades back we had the ability to cryogenically freeze processes, save them to storage, move the bins to another system, and defrost them to be run again. This was a great feature that I had hoped would make its way into mainstream kernels, but it seems to have disappeared off the face of the earth. I wonder if the expansion of process isolation tooling will ever lead us back to this situation again, anyone kn…
A bit of tangent, but reminds me of the Deep Freeze Windows app: https://www.faronics.com/products/deep-freeze I wonder if a similar tool exists for Linux.
it'd be interesting to see a comparison of these -- the building blocks are (mostly) the same, but the interfaces differ in interesting ways: - nsjail - firejail - bubblewrap - runc etc.
As a bubblewrap user, beware https://github.com/containers/bubblewrap/pull/586 still missing. The usual ^C doesn't work with your sandboxed stuff, very annoying. A cursory look at NSjail tells me its filesystem stuff is less granular than bwrap's bind mounting. Firejail can't handle : in some paths (at all, no escaping provided) which made me dump it.
This doesn't match my experience. For example, the following works just fine in a profile file:
blacklist /sys/devices/pci0000:00/*
A few decades back we had the ability to cryogenically freeze processes, save them to storage, move the bins to another system, and defrost them to be run again. This was a great feature that I had hoped would make its way into mainstream kernels, but it seems to have disappeared off the face of the earth. I wonder if the expansion of process isolation tooling will ever lead us back to this situation again, anyone kn…
CRIU is used lots of places for Linux processes but in my experience is far more low level and finicky and it tends to do things that require root permissions. It's used in production, but I would be shocked if, for example, someone made it so k8s could just live migrate any pod with CRIU.
Just think of the possible ways apps that might break if you changed their hostname or pid out from under them. And that's not even including stuff like connections to localhost or shared memory.
Earlier quoted context omitted.
As a bubblewrap user, beware https://github.com/containers/bubblewrap/pull/586 still missing. The usual ^C doesn't work with your sandboxed stuff, very annoying. A cursory look at NSjail tells me its filesystem stuff is less granular than bwrap's bind mounting. Firejail can't handle : in some paths (at all, no escaping provided) which made me dump it.
> Firejail can't handle : in some paths (at all, no escaping provided) which made me dump it. This doesn't match my experience. For example, the following works just fine in a profile file: blacklist /sys/devices/pci0000:00/* Can you give an example of what you had problems with?
cf https://github.com/netblue30/firejail/issues/4614, https://github.com/netblue30/firejail/blob/master/src/fireja... and https://github.com/netblue30/firejail/blob/master/src/lib/co...
Earlier quoted context omitted.
It's still a reasonable comparison though. The seccomp-bpf is part of nsjail is achieving the same thing, one way to look at it is that Landlock/pledge are just a better implementation for the same approximate feature.
I don't really find it reasonable, landlock type functionality is a tiny subset of what namespace based sandboxing offers. It's like comparing a scanner to authenticate ID cards against a fortified house.