Server-side sandboxing: Containers and seccomp
1–10 of 47 posts
Re: Server-side sandboxing: Containers and seccomp
#2We had seccomp containers at Dropbox, and I remember Max Serrano helping me set that up with ReactServer :) Talented engineer, though I do remember that the jails were kind of a maintenance nightmare for the security team.
Re: Server-side sandboxing: Containers and seccomp
#3Nice, love seccomp though as with all things security it can be very fiddly.
Re: Server-side sandboxing: Containers and seccomp
#4If 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/...)
Re: Server-side sandboxing: Containers and seccomp
#5I 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 it be considered a replacement at this point?
It seems like it could handle the last scenario described in the article fine, since it allows setting granular rwcx permissions on individual paths.
Re: Server-side sandboxing: Containers and seccomp
#6It's pretty easy to apply seccomp to a process using systemd by adding SystemCallFilter= in its unit file. There's a reasonable set of permitted syscalls for general system processes, aptly called `@system-service`, but you can tweak that to suit your needs [1]. I generally use this, among other settings, to further lock down system services [2].
[1] https://www.freedesktop.org/software/systemd/man/latest/syst...
Re: Server-side sandboxing: Containers and seccomp
#7seccomp is heaps better than selinux, but still too overly complicated to be using in everyday production unless you're truly on the "refine and secure" path or dealing with high-stakes sandboxing.
Re: Server-side sandboxing: Containers and seccomp
#8I 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…
>Digging through a mountain of strace output is tedious
did you consider logging the syscalls invoked during normal usage with 'strace --output=/some/dir -f ...'? This + grep + uniq should make it really simple.
Re: Server-side sandboxing: Containers and seccomp
#9I 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…
We too ended up adding pledge and unveil to Nanos.
Seccomp and seccomp-bpf are indeed entirely way too limiting. It wasn't really designed for end app developers who are, imo, the ones that should be dictating the policy. The whole lack of pointer deref'ing makes it really difficult for application level developers to make policies that are easier to create.
The promises arg in pledge, https://man.openbsd.org/pledge.2 , does a decent job of grouping related calls together but I think there is a ton of room to make all of this a lot better than it is today.
Re: Server-side sandboxing: Containers and seccomp
#10I 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 really matter if it's pledge or seccomp at that point (although undoubtedly seccomp is far harder to make use of), if you're doing this kind of security by retroactive whitelist, you're going to have trouble making it work. It's going to take time and effort to implement.