7 ms·

I don’t think it’s misleading - working in security, I can tell you that containers are misconfigured with too many privileges everywhere you look. SWEs like fo

by t8sr 3y ago

I don’t think it’s misleading - working in security, I can tell you that containers are misconfigured with too many privileges everywhere you look. SWEs like focusing on cool stuff, like kernel exploits, to the detriment of basic production security. From the point of view, this is an article I think many SWEs could benefit from reading, especially on teams that do their own deployments.

mmis1000 3y ago
For example, it isn't that weird to give container access to ptrace cap. Sys_ptrace is a important capacity if you need to profile the process for whatever reason. Sys_admin is required to mount a tmpfs file system even it don't actually modify any file. There are cases that these are actually required. And you don't know what may also cause security issue and why it isn't given by default if you did not read about that.
- ptx 3y ago
  The "escape" in the article also requires "--pid=host", i.e. permission to debug processes on the host. That seems like a very obviously bad idea.
  - mmis1000 3y ago
    For interactive debug, maybe? Container can be used a a dev environment to dev/test things that would otherwise affect the host irreversibly. For example: something like installer.
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 ago
  Yeah, 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.

by t8sr 3y ago

mmis1000 3y ago

For example, it isn't that weird to give container access to ptrace cap. Sys_ptrace is a important capacity if you need to profile the process for whatever reason. Sys_admin is required to mount a tmpfs file system even it don't actually modify any file. There are cases that these are actually required. And you don't know what may also cause security issue and why it isn't given by default if you did not read about that.

ptx 3y ago
The "escape" in the article also requires "--pid=host", i.e. permission to debug processes on the host. That seems like a very obviously bad idea.
- mmis1000 3y ago
  For interactive debug, maybe? Container can be used a a dev environment to dev/test things that would otherwise affect the host irreversibly. For example: something like installer.

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 ago
Yeah, 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.