Live data from Hacker News

Server-side sandboxing: Containers and seccomp

figma.com

21–30 of 47 posts

Re: Server-side sandboxing: Containers and seccomp

#21

Good 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.

Re: Server-side sandboxing: Containers and seccomp

#22
post #19
post #10

Earlier quoted context omitted.

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…

> 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. Quite the contrary. If the software in question has been written in a remotely sane way, adding some basic pledge restrictions is a matter of adding one line: pledge("stdio rpath whatever you need", NULL) - it…

I think realistically most of the things people seriously care about pledging are complex application and server software so yes the point is you run into problems trying to pledge things. Obviously you can come up with the minimum set of things you can pledge pretty quickly to get things working, but that doesn't guarantee they will keep working. And you can also be very broad, but there's a point at which that doesn't gain you much in terms of security (or as much as you may have set out to gain).

This reminds me of a situation where I tried to use firejail to isolate this proprietary piece of software, I ran firejail in the "auto-generate-something-sensible" mode and then tried running it in that profile. It would just randomly break at that point. I never quite figured this out due to lack of time. I was expecting to be able to roll with an auto-generated profile at first and tighten it later, the actual end result was there was no profile at all.

The other issue you run into is getting things which work sometimes and then stop working randomly. Especially when it's a large graphical application. It will do something strange when you click a specific button and crash. Now you are annoyed, probably not in the mood to debug this, so maybe you make a note for later. Now you have to recreate the issue under strace, figure out what you need to pledge now, and repeat.

Yes, if you're trying to pledge ls, it's pretty easy. If you're trying to pledge anything non-trivial (i.e. anything which would _really_ benefit from these security restrictions) you end up iterating a lot.

It's not very fun.

Re: Server-side sandboxing: Containers and seccomp

#23

If 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/... )

Running arbitrary user code inside a jail that doesn’t isolate networking might not be enough isolation. Also kernel mount namespace binds into the jailed env increases the attack surface. Great for some use-cases, but multi-tenant workloads might need a tighter setup? I'm definitely going to give Windmill a try. It looks really cool!

Re: Server-side sandboxing: Containers and seccomp

#24

If 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/... )

Wow, this nsjail setup is now part of your opensource version? Last I tried Windmill there was no isolation mechanism for scripts on the free version.

Re: Server-side sandboxing: Containers and seccomp

#25
post #21

Good 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.

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.

Re: Server-side sandboxing: Containers and seccomp

#28
post #5

I 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…

Despite the availability of linux pledge, and frequent comments mentioning its existence, I'm not aware of many people using it.

I think it would acquire more usage if it was part of mainline Linux distros. As far as I can tell people must feel like this is some kind of optional, nonstandard thing.

It works well with openbsd because its standard, and most if not all openbsd packages make use of it

Though maybe I'm misunderstanding how Linux pledge works. I'm only familiar with the openbsd usage of it

Re: Server-side sandboxing: Containers and seccomp

#29
post #11

If 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…

Oddly enough the canonical extension seems to now be none of those but .txtpb:

https://protobuf.dev/reference/protobuf/textformat-spec/#tex...

Re: Server-side sandboxing: Containers and seccomp

#30
post #20

So what's the difference between nsjail[1] and bubblewrap[2]? [1] https://github.com/google/nsjail [2] https://github.com/containers/bubblewrap

bubblewrap aims to be reasonably secure by default but leaves sleeping soundly at night as an exercise to the reader. It's not exhaustive. It's more of a blast radius/convenience tool. Conversely nsjail aspires to facilitate sleeping soundly out of the box, with security as the primary motivating factor.
Post reply on HN