Are operating systems failing at their jobs if one can't run independent workloads on them anymore?
It seems like something is broken, and we are all patching things up piecemeal.
Server-side sandboxing: Containers and seccomp
31–40 of 47 posts
Re: Server-side sandboxing: Containers and seccomp
#32Are operating systems failing at their jobs if one can't run independent workloads on them anymore? It seems like something is broken, and we are all patching things up piecemeal.
Yes and yes.
Re: Server-side sandboxing: Containers and seccomp
#33Good intro. I'd be curious how they do the syscall tracing, eg, strace logs as part of CI? Funny enough, we've gone the reverse path for LLM AI-generated code sandboxing for louie.ai / Graphistry . We started with container isolation with careful network, volume, compute etc enablement first, and only now adding nsjail to the runners within the container as an extra defense layer. The negative space is interesting to…
I have yet to find a firecracker-style thing for k8s that is simple to deploy. Firekube seemed interesting, but is archived... Liquid Metal from Weaveworks seems interesting but I don't even know where I would start.
Virtink[1] has been reasonably stable as long as you're okay with Cloud Hypervisor instead.
Re: Server-side sandboxing: Containers and seccomp
#34So what's the difference between nsjail[1] and bubblewrap[2]? [1] https://github.com/google/nsjail [2] https://github.com/containers/bubblewrap
I don't have extensive experience with nsjail, but from reading the docs it seems to me like nsjail covers namespaces, cgroups and virtual networking, while bwrap only covers namespaces. On the other hand, bwrap is deliberately kept simple because it is SUID.
Re: Server-side sandboxing: Containers and seccomp
#35Earlier quoted context omitted.
I have yet to find a firecracker-style thing for k8s that is simple to deploy. Firekube seemed interesting, but is archived... Liquid Metal from Weaveworks seems interesting but I don't even know where I would start.
Kata just released a new version, it is the only thing that I've found easy to setup with k8s... though my experience running Docker-in-Kata hasn't been very good.
We were looking at Kata as well, especially as an 'easier' firecracker, though I forgot why we didn't go further, and I've been curious why they seem to get little attention in practice
I believe part is portability, as they may require nested virtualization features to be available, and maybe QEMU overhead. Maybe also something about use in China vs elsewhere?
They (and QEMU) have been around a long time...
Re: Server-side sandboxing: Containers and seccomp
#36Is there an isolation method close to the functionality to nsjail but for .net code? I know I can protect my AppDomain but how to protect the system/network from rouge .net code?
Re: Server-side sandboxing: Containers and seccomp
#37I haven't used seccomp, but have recently been playing around with the Linux pledge port[1]. It has a very friendly UI, but I still struggled with allowing some complex apps to run at all, because of the sheer amount of syscalls and devices they required. Digging through a mountain of strace output is tedious... Can someone with experience with both comment on how (the Linux port of) pledge compares to seccomp? Can i…
Pledge works well if the software developers implement it on their own application. It also works well if the software developers document what syscalls they rely on and what permissions they need. When it comes to retrofitting something like pledge (or seccomp) into an existing application when you've not developed it and/or can't easily tell what syscalls are being called then it's always a nightmare. It doesn't re…
And it’s not just your application, too: it’s what you depend on. Surely your command line application that works with a handful of files is fine with read/write? Your libc might be using something else like iovec or press/pwrite under the hood.
Re: Server-side sandboxing: Containers and seccomp
#38Are operating systems failing at their jobs if one can't run independent workloads on them anymore? It seems like something is broken, and we are all patching things up piecemeal.
It’s actually not that hard to make OSes that run completely independent workloads. The problem is that this is not useful.
Re: Server-side sandboxing: Containers and seccomp
#39If you are looking to self-host a scalable backend that runs arbitrary code in python/typescript/bash/go with optional sandboxing using nsjail like figma, nsjail is what we use as isolation layer at https://windmill.dev (Open-source alternative to Retool/Airplane) (Our python nsjail config for instance: https://github.com/windmill-labs/windmill/blob/main/backend/... )
nsjail author here (the original one, as the tool is also maintained by others), good job! Irrelevant nit: .proto files are protobuf definition files (like this one: https://github.com/google/nsjail/blob/master/config.proto ), a text representation of a specific protobuf contents is typically called (as per man clang-format): .textpb .pb.txt or .textproto - I use .config for examples distributed with nsjail, but it's…
Why not just use json?
Re: Server-side sandboxing: Containers and seccomp
#40Seccomp BPF is great. There was some recent issues due to IO_uring and extensible syscalls, but I believe for now, those issues are avoidable. I believe the next generation looks something like landlock ( https://docs.kernel.org/userspace-api/landlock.html ).
+1