Sometimes during a container or Kubernetes assessment, we get requested to review whether a runtime security tool that a client uses is sufficient for their threat model. This often means reviewing a custom seccomp-bpf profile, AppArmor config, or third party tool that tries to enforce the isolation between a container and the host. There’s two approaches we usually take during these gigs: Audit the profile and identify any flaws or bypasses that could exist Analyze the container at runtime to validate the policy actually enforces the expected ruleset.

By default Docker allows all of their containers to run with the CAP_NET_RAW capability, I believe to easily support ICMP health checks when needed. Supporting ping makes sense but this post will go through why CAP_NET_RAW is an unnecessary risk and how you can still send pings without needing CAP_NET_RAW. What does CAP_NET_RAW do? CAP_NET_RAW controls a processes ability to build any types of packets that you want. TCP, UDP, ARP, ICMP, etc.

After 8 years of Security B-Sides Rochester, it’s time for me to turn it over to new leadership that wants to keep the conference going. It’s exciting that people still want to. My role as of recent has been the person that invested the most time doing the running around to organize the conference but that’s not to say I “run” the conference – it truly is run by volunteers and one of my jobs was to try and maintain some consistency while letting people do what they want.

The folks at Rochester 2600 were regaled by a talk from Payap Sirinam who is on Matthew Wright’s academic team at RIT. They’re working on an interesting system that aims to defend against website fingerprinting attacks – a major threat to anonymity systems like tor. As in, if you’re using tor, passive adversaries in position to watch traffic between the tor client and a guard, can determine the website you’re visiting… with frightening accuracy.