4 ms·

I don't think it's worth doing all these tweaks. The first reason is that it's all running on Linux anyway, and Linux is (in general) swiss cheese, security-wi

I don't think it's worth doing all these tweaks. The first reason is that it's all running on Linux anyway, and Linux is (in general) swiss cheese, security-wise. Even with a billion container tweaks, there are still holes that can be exploited from the container to escalate to the host OS. The second is that attacks don't need to privilege-escalate to the host to cause havoc. If the attacker can read memory, they can get credentials for other network services and exploit them from the container. Or they can drop malware from the container to any users of a service, or upload it to a service. Or they can just scan the network looking for another vulnerable service. Or it could be something like EC2/ECS Metadata Service was left accessible and they can start enumerating your cloud account(s). More than enough for the average attacker. Just assume that a Docker container is exactly the same as running a regular process on the host OS, and it will be much simpler to identify attack surfaces and mitigate them.

KronisLV 5y ago
> I don't think it's worth doing all these tweaks. I feel like i can understand this point of view, since following all of that advice indeed would be cumbersome. However, at the same time you definitely have to consider what it is that you're running on your infrastructure. A small internal system or even an ERP that's not exposed to the internet will probably give you more leeway in regards to being able to ship stuff now, without spending bunches of time locking everything down, especially if you build all of the containers yourself. On the other hand, a large finance application that is publically accessible and needs to weather thousands of attacks daily will probably need a rather different approach. Overall, however, i'd say that it's good to have lists of tips like these, because figuring out all of it alone would take a whole lot of time. That said, even in the more relaxed environments, it's generally a good idea to consider at least some of them, for example: > Unless you are very confident with what you are doing, never expose the UNIX socket that Docker is listening to: /var/run/docker.sock Being an early adopter of Docker, i once made this mistake on a throwaway VPS. It took less than 24 hours for it to be mining crypto. That said, the socket can be a good option for tools like Portainer (which implementations like Podman miss out on), yet it definitely should never be exposed publically. As always, security isn't a boolean of on/off, but rather is a sliding scale of sorts - figure out the risks that you're likely to be facing and choose the appropriate means to combat them. Of course, it would be better if Docker provided safer defaults, too.
raesene9 5y ago
I'd say it depends very much on your threat model. Would I trust a Docker container with a hostile multi-tenant setup without additional controls.... no. Is the isolation provided by Docker worth nothing, from a security perspective... also no :) Hardening containers is a good element of an overall security strategy. It needs to be combined with other controls, both preventative controls at things like the network layer, and detective controls to spot when a preventative control fails and allow for rapid mitigation.
- throwaway984393 5y ago
  Sure, but prioritization is important here too. I would rather work on detective controls first and identify the large attack surfaces / weakest links, and only much later look at system hardening. (But to clarify I don't consider things like patch management to be system hardening)

KronisLV 5y ago

> I don't think it's worth doing all these tweaks. I feel like i can understand this point of view, since following all of that advice indeed would be cumbersome. However, at the same time you definitely have to consider what it is that you're running on your infrastructure. A small internal system or even an ERP that's not exposed to the internet will probably give you more leeway in regards to being able to ship stuff now, without spending bunches of time locking everything down, especially if you build all of the containers yourself. On the other hand, a large finance application that is publically accessible and needs to weather thousands of attacks daily will probably need a rather different approach. Overall, however, i'd say that it's good to have lists of tips like these, because figuring out all of it alone would take a whole lot of time. That said, even in the more relaxed environments, it's generally a good idea to consider at least some of them, for example: > Unless you are very confident with what you are doing, never expose the UNIX socket that Docker is listening to: /var/run/docker.sock Being an early adopter of Docker, i once made this mistake on a throwaway VPS. It took less than 24 hours for it to be mining crypto. That said, the socket can be a good option for tools like Portainer (which implementations like Podman miss out on), yet it definitely should never be exposed publically. As always, security isn't a boolean of on/off, but rather is a sliding scale of sorts - figure out the risks that you're likely to be facing and choose the appropriate means to combat them. Of course, it would be better if Docker provided safer defaults, too.

raesene9 5y ago

I'd say it depends very much on your threat model. Would I trust a Docker container with a hostile multi-tenant setup without additional controls.... no. Is the isolation provided by Docker worth nothing, from a security perspective... also no :) Hardening containers is a good element of an overall security strategy. It needs to be combined with other controls, both preventative controls at things like the network layer, and detective controls to spot when a preventative control fails and allow for rapid mitigation.

throwaway984393 5y ago
Sure, but prioritization is important here too. I would rather work on detective controls first and identify the large attack surfaces / weakest links, and only much later look at system hardening. (But to clarify I don't consider things like patch management to be system hardening)