4 ms·

Not all servers are containerized, but a significant number are and they present their own challenges. Unfortunately, many such tools in docker images will be

by devsda 3y ago

Not all servers are containerized, but a significant number are and they present their own challenges. Unfortunately, many such tools in docker images will be flagged by automated security scanning tools in the "unnecessary tools that can aid an attacker in observing and modifying system behavior" category. Some of those ( like having gdb) are valid concerns but many are not. To avoid that we have some of these tools in a separate volume as (preferably) static binaries or compile & install them with the mount path as the install prefix (for config files & libs). If there's need to debug, we ask operations to mount the volume temporarily as read-only. Another challenge is if there's a debug tool that requires enabling a certain kernel feature, there are often questions/concerns about how that affects other containers running on the same host.

Too 3y ago
A better way is to build a second image including the debug tools and a root-user, then start it with the prod-containers pid-namespace and network-namespace mounted. Starting a second container is usually a good idea anyway, since you need to add a lot of extra flags like SYS_PTRACE capability, user 0 and --privileged for debuggers to work. This way you don't need to restart the prod-container either, potentially loosing reproduction-evidence. Remembering how to do all this in an emergency may not be entirely obvious. Make sure to try it first and write down the steps in your run books.
- devsda 3y ago
  > A better way is to build a second image including the debug tools and a root-user. That was our initial idea. But management and QA are paranoid enough that they consider these as new set of images that require running the complete test suite again even when they are built on top of certified images. Nobody is willing to test twice, so we had to settle for this middle.
remram 3y ago
If an attacker can execute files from the filesystem, and all that's missing to run them is them being present on the filesystem, the attacker could just... write those files themselves? I really don't understand in what scenario this policy makes any sense, apart from "my organization misuses security scanners".

by devsda 3y ago

Too 3y ago

A better way is to build a second image including the debug tools and a root-user, then start it with the prod-containers pid-namespace and network-namespace mounted. Starting a second container is usually a good idea anyway, since you need to add a lot of extra flags like SYS_PTRACE capability, user 0 and --privileged for debuggers to work. This way you don't need to restart the prod-container either, potentially loosing reproduction-evidence. Remembering how to do all this in an emergency may not be entirely obvious. Make sure to try it first and write down the steps in your run books.

devsda 3y ago
> A better way is to build a second image including the debug tools and a root-user. That was our initial idea. But management and QA are paranoid enough that they consider these as new set of images that require running the complete test suite again even when they are built on top of certified images. Nobody is willing to test twice, so we had to settle for this middle.

remram 3y ago

If an attacker can execute files from the filesystem, and all that's missing to run them is them being present on the filesystem, the attacker could just... write those files themselves? I really don't understand in what scenario this policy makes any sense, apart from "my organization misuses security scanners".