This is a follow up from the Custom Seccomp profile post which went through some of the background information. Speed up custom seccomp profile generation with Syscall2seccomp You can always manually track down the syscalls that your application makes, and build a custom seccomp profile for your Docker container, but I’ve created the tool syscall2seccomp that helps speed the profile building process up. It takes the output from sysdig or strace and converts it to a usable Docker profile.
This post goes through building custom Docker seccomp profiles for your container. I’m not recommending you do this especially in enterprise environments, but I’m being charitable to the idea that system call filtering is the basis of a lot of sandboxing technologies and filtering out unnecessary ones should reduce the attack footprint of your application. This is more of an exploration of use-cases for custom Docker seccomp profiles than a suggestion that everyone does this themselves.
This post goes into what tor’s onion service authentication features do, how they work, and when they should be used based on your threat model because I couldn’t find any other documentation about it besides reading the spec. “Stealth” only provides “stealthy” properties against malicious HSDirs and basic has some additional obfuscation measures that might make your service better protected. Onion Service Authentication Feature An onion/hidden service supports two types of built in authentication:
One of Docker’s many updates this year was adding seccomp support. In short, seccomp/secomp-bpf is a way of filtering the system calls that you want to allow an application to make. It’s used for sandboxing enforcement it a lot of projects including Chromium, bubblewrap, and SubgraphOS. In Docker, it’s enabled by default (in supported environments) and has a default profile that is fine, but there’s always ways to customize it.