Sandboxes, Seccomp, and Syscalls Building Insecure and Incomplete Profiles Bypasses and Breakouts Measuring Scoring and Scaling with Seccompute I’ve been describing a common thread throughout these posts which is we can spend hours building artisinally crafted seccomp profiles and say that everything is more secure, but we don’t inherently know that. We just assume. And even when we want to measure if a given seccomp profile is “good” there’s an immense amount of complexity to come to that decision.

Sandboxes, Seccomp, and Syscalls Building Insecure and Incomplete Profiles Bypasses and Breakouts Measuring Scoring and Scaling with Seccompute The other post, I’ve been mostly describing the operational burden of managing seccomp profiles and describing scenarios where the seccomp profile might not be as effective as we think. This is the post I wanted to get back attacker perspective. You have a container. Seccomp is enabled. The profile looks reasonable – no bpf, no ptrace, network syscalls restricted. What’s do we do?

Sandboxes, Seccomp, and Syscalls Building Insecure and Incomplete Profiles Bypasses and Breakouts Measuring Scoring and Scaling with Seccompute The idea behind seccomp profiles for a container is simple: your container makes good syscalls, let’s block the bad system calls. So you record the syscalls your container makes, build a seccomp JSON profile that allows only those syscalls, then anything your app didn’t call, gets blocked. Minimal attack surface. Perfect. We did our job?

Sandboxes, Seccomp, and Syscalls Building Insecure and Incomplete Profiles Bypasses and Breakouts Measuring Scoring and Scaling with Seccompute It’s been a few weeks since I presented at BSidesSF. A talk called “Sandboxes, Seccomp, and Syscalls: Chasing Isolation in Kubernetes”. Since then, I wanted to dump the details of the talk and some of the points I was trying to make. The overall point of the talk: “Seccomp in Kubernetes, you’re holding it wrong”. I wanted to appreciate teams that are doing seccomp in k8s at scale, and warn anyone that is taking the CKS exam to think critically about using seccomp to harden workloads.

Just leaving DEFCON and wanted to post my slide deck from the DEFCON Cloud Village. It’s a 20 minute talk so I focused on container registries with read access and write access. Here’s the deck: DEFCON Cloud Village go-pillage-registries The main take-away from the talk was based on a discussion at work about the whiteout files used by the overlay file system. Registry Pillage 2.0: More Pillaging, More Whiteouts I’m resurrecting a tool that Josh Makinen wrote while we were at NCC Group: antitree/go-registry-pillage. This pentesting utility targets container registries you can access—whether your own or ones you stumble onto during a penetration test. It’s statically compiled so you can curl|bash it in when you’re dropped into a shell inside a Pod.

Seccompare.com quickly compares two container seccomp profiles and includes a handy syscall lookup table. Are you interested in some practical guidance for applying custom seccomp profiles for a container? You aren’t?? Too bad. Here it comes. Check out https://www.seccompare.com Custom Seccomp Profile Auditor Here’s what it is: Let’s assume the role as the worlds greatest security engineer with an expertise in containers. As that expert you may recommend overriding the default seccomp profile that gets applied by default today, with a more custom, artisinally crafted, purposefully built seccomp-bpf profile that is intended to restrict your container to only perform operations that you support.

seccomp-diff extracts the real seccomp filters straight from a running container Reverse engineering BPF taught me more about containers and syscalls than I expected seccomp good, seccomp at scale hard Ever wonder if the seccomp profile Docker or Kubernetes thinks it’s applying is the same one actually enforcing syscalls inside your container? Sure, we all do, right? Well I wrote seccomp-diff, a tool that digs into a live process using ptrace, extracts out the seccomp BPF bytecode and lets you compare it with the default seccomp profile that is applied in the cluster or other containers that are running.

Take-aways Container registries are simple services ripe for subtle abuse They are trusted endpoints making them useful for exfil and post-exploitation It’s easy to make a malicious file appear like a legitimate image layer I’m beating up container environments in the context of supply chain threats over the last few months. If you’re working in the container or Kubernetes security area, you’re constantly running into the reality that many of the exploits that you know about, are not going to be the next major cyber event on the front page of news sites. This post will go through another attack path using container registries that although seemingly impactful to supply chain security, will likely not be a threat at scale.

UPDATE 11/28/2020: Thanks to @jaybeale and @sethsec for pointing out I was calling it “OPA Gateway” instead of OPA Gatekeeper. UPDATE 3/20/2021: Tim Allclair and Jordan Liggitt have a proposal with a demo that shares what PSPs may look like in the future. 3-Tier Pod Security Proposal. It’s talking about turning the ideas of PSP’s into an admission controller that implements the “Pod Security Standards” mentioned above. UPDATE: 4/8/2021 …And now they are. PSPs have been deprecated as planned starting with 1.21. Hopefully in 1.22, a new Alpha feature currently called Pod Security Policy Replacement Policy will hopefully land that you can use. There are no direct paths that I know of for migrating to anything besides a third party admission controller if you’re using 1.21.

I’m writing about the Kubernetes API’s use of the “LIST” verb it controls access to Secrets in a cluster. I’ve seen way too may environments, tools, templates, and examples that are hoping that LIST verbs can provide a meaningful security control compared to the GET verb. I’m going through a simple demo below and a few one-liners that can help you audit this yourself. Background Kubernetes Roles are designed to give fine grained access to various API actions within the cluster by defining “Verbs” that you’re allowed to send to the API. GET, LIST, UPDATE, CREATE… and a bunch more.