4 ms·
In practice, though, containers are given these capabilities all the time, and in infosec people do refer to these as escapes. Generally, it’s not the stuff th
by t8sr 3y ago
In practice, though, containers are given these capabilities all the time, and in infosec people do refer to these as escapes.
Generally, it’s not the stuff the container is intended to run that’s doing the escape, though. This is usually the second step, after getting local execution through a vulnerability in the application running in the container.
- ptx 3y agoWhy are these capabilities usually granted, in your experience?
- achierius 3y agoIn my experience profilers often need SYS_ADMIN or other capabilities. This is true even outside of a container. If I'm forced to work inside a container without the ability to add that cap, performance optimization work becomes very difficult.
- blackmesaind 3y agoUser error is the source of many vulnerabilities that shouldn't exist.
- t8sr 3y agoI posted another comment with some examples, but I think the general answer, IME, is that it's usually easier to do the wrong thing than to do the right thing. Security boundaries in Cloud-style Linux are typically hard to configure and not well documented. Engineers have deadlines and they're interested in building things, not debugging permissions. They'll do whatever is the easiest to get the system working. This, by the way, is why I think Google had it right by splitting most products into SWE and SRE groups, so you had a group of people who could focus full-time on the production environment. SWEs are rewarded for building and deploying stuff, so they're going to build and deploy stuff.