3 ms·
That's interesting. Do you mean you see containers that aren't running with "least possible privileges" more narrow than the defaults, or that you often see mi
by fulafel 3y ago
That's interesting. Do you mean you see containers that aren't running with "least possible privileges" more narrow than the defaults, or that you often see misconfigurations such as the ones described in this article? Are the people still thinking the container works as as a security boundary after this, or are they knowingly turning off security to get to some functionality that otherwise doesn't work with the normal confines of a container?
- t8sr 3y agoYeah, lots. The reasons are many, and pretty diverse, otherwise I think it'd be easier to fix. Some examples: - You need to mount a filesystem, use a raw socket, etc. and Stack Overflow / ChatGPT tells you to enable a capability, so you do. It works, so you check it in. - You're deploying something legacy, that assumes it has more control of the OS than it does inside a container. - You're a data engineer. All of your tools assume they run as root, because that's just how data science is. - You're building a "sidecar" for monitoring, control over other containers or something similar. The extra privileges are needed to do your job. - You're trying to access something you can't, and it's generally easier to overprovision access than to do least privilege. These problems aren't unique to containers and the cloud, mind you. I saw the same problems, e.g. when working on mobile device security. In general, it's a lot easier to just turn off half of SELinux than to learn how to configure it to do what you want, especially if you have a deadline.