8 ms·

A container is not a VM and should ONLY contain the exact files needed to run your app to run securely. Any additional packages increase the security footprint.

A container is not a VM and should ONLY contain the exact files needed to run your app to run securely. Any additional packages increase the security footprint. Every container is one RCE vulnerability away from being compromised and escaped. if your images are distribution based, even slim ones, you’re giving the attacker a broad set of tooling out of the box. Container runtime defaults in Docker and Kubernetes are insecure and grant attackers a lot of privilege — running as UID 0, no user namespace separation, and potentially dangerous kernel capabilities added to the container’s parent process.

foldr 6y ago
Just on a slight tangent, what are the security benefits of having a process run as a non-root user within a Docker container? It's obvious what the benefits are when running outside a container. Inside a container, on the other hand, there should only really be one important process running. That process will need to have access to all the interesting parts of the file system anyway, and being root inside a container doesn't let you do crazy superuser stuff like installing a kernel module.
- deleted 6y ago
  [deleted]
- Cthulhu_ 6y ago
  It does allow you to exit the boundaries of the application though, and e.g. extract the application's database. That said, is it possible to disable superuser access entirely in a container? Can't login as root if there is no root.
  - mattacular 6y ago
    Docker has a user namespacing feature which can be used to harden container images and also a newer way to run rootless altogether - https://docs.docker.com/engine/security/rootless/ https://docs.docker.com/engine/security/rootless/
  - nix23 6y ago
    https://developers.redhat.com/blog/2020/09/25/rootless-containers-with-podman-the-basics/ https://developers.redhat.com/blog/2020/09/25/rootless-conta...
  - dec0dedab0de 6y ago
    If the application user has access to the database, it doesn't matter if you get access to root or not.
- mattacular 6y ago
  If you've got root on a container, depending on how it's configured, you can gain access to the host in some situations (eg. Using volumes)
  - foldr 6y ago
    But non-root users within the container can also access mounted volumes, no? Is there some kind of exploit that only works if running as root?
    - lights0123 6y ago
      You can setuid root in a volume mounted in host. If that's executed at all by any user, bam you have root on the host. If it's never executed, I don't know what vulnerabilities they were talking about.
      - foldr 6y ago
        Right, but it seems that wouldn't require the app within the Docker container to be running as root to work?
  - nix23 6y ago
    What a shitty concept. Typical Linux NIH (learn from zones jails lpar...no we need to reinvent the wheel in square format)
    - turminal 6y ago
      Linux namespaces are quite flexible and aren't used just for docker style containerization. In some use cases having a shared user namespace makes sense. Docker just doesn't use the provided interface by default. Which is a shame because a lot of users don't bother or don't know they should bother to configure it. I think that's kind of a 'we don't care about security' move by docker and given its userbase that's a real problem.
      - 6y ago
- coredog64 6y ago
  If you don’t at least drop the sys_module cap, you can install a kernel module [0]. Running as root inside the container increases the risk of a breakout. I’ve seen different approaches at different companies. One bank required a hard-to-get security sign off that included MFA to start (so no automation). A different bank bought expensive monitoring tools and then threw a bunch of money at refining the outputs. [0] https://blog.pentesteracademy.com/abusing-sys-module-capability-to-perform-docker-container-breakout-cf5c29956edd?gi=561118cc2eee https://blog.pentesteracademy.com/abusing-sys-module-capabil...
tpetry 6y ago
The problem is adding ONLY the exact files needed is currently impossible when building docker containers. If you are building go/rust executables this easy, you will get one executable you'll add. But if you need to pull in some dependency by a package manager you are lost, they will pull in so many dependencies you may not need but are not defined optional by the packages. A small container is really impossible.
- jbverschoor 6y ago
  No it's perfectly possible, but people are just lazy and/or don't understand their platforms. Docker is for many a "simple" way of getting their app running, and once it's up, they never look back.
- folkrav 6y ago
  There are ways, but they aren't particularly obvious and are more work than they should. With some elbow grease involving multi-step builds, snapshots and diffing the resulting images to copy only the required files into your final image, you can definitely build them, at least. It isn't made particular easy for you. Honestly it's actually kind of a pain, wherein lies the problem. Doesn't help that some languages' official images are kind of bloated themselves, either.
  - mikeyjk 6y ago
    Is diffing images really necessary? I've done multi step builds in the past for a Java app and I didn't find it especially hard to only include what was required. E.g. the final resultant image would exclude maven, which would be used in the first stage of the build.
    - tpetry 6y ago
      Multi Step Images will not help if you want to build a python container and the package manager will pull in e.b. Bash for the python runtime snd many more depencies. It only saves you from adding build tools to the image.
    - 6y ago

foldr 6y ago

Just on a slight tangent, what are the security benefits of having a process run as a non-root user within a Docker container? It's obvious what the benefits are when running outside a container. Inside a container, on the other hand, there should only really be one important process running. That process will need to have access to all the interesting parts of the file system anyway, and being root inside a container doesn't let you do crazy superuser stuff like installing a kernel module.

deleted 6y ago
[deleted]
Cthulhu_ 6y ago
It does allow you to exit the boundaries of the application though, and e.g. extract the application's database. That said, is it possible to disable superuser access entirely in a container? Can't login as root if there is no root.
- mattacular 6y ago
  Docker has a user namespacing feature which can be used to harden container images and also a newer way to run rootless altogether - https://docs.docker.com/engine/security/rootless/ https://docs.docker.com/engine/security/rootless/
- nix23 6y ago
  https://developers.redhat.com/blog/2020/09/25/rootless-containers-with-podman-the-basics/ https://developers.redhat.com/blog/2020/09/25/rootless-conta...
- dec0dedab0de 6y ago
  If the application user has access to the database, it doesn't matter if you get access to root or not.
mattacular 6y ago
If you've got root on a container, depending on how it's configured, you can gain access to the host in some situations (eg. Using volumes)
- foldr 6y ago
  But non-root users within the container can also access mounted volumes, no? Is there some kind of exploit that only works if running as root?
  - lights0123 6y ago
    You can setuid root in a volume mounted in host. If that's executed at all by any user, bam you have root on the host. If it's never executed, I don't know what vulnerabilities they were talking about.
    - foldr 6y ago
      Right, but it seems that wouldn't require the app within the Docker container to be running as root to work?
- nix23 6y ago
  What a shitty concept. Typical Linux NIH (learn from zones jails lpar...no we need to reinvent the wheel in square format)
  - turminal 6y ago
    Linux namespaces are quite flexible and aren't used just for docker style containerization. In some use cases having a shared user namespace makes sense. Docker just doesn't use the provided interface by default. Which is a shame because a lot of users don't bother or don't know they should bother to configure it. I think that's kind of a 'we don't care about security' move by docker and given its userbase that's a real problem.
    - 6y ago
coredog64 6y ago
If you don’t at least drop the sys_module cap, you can install a kernel module [0]. Running as root inside the container increases the risk of a breakout. I’ve seen different approaches at different companies. One bank required a hard-to-get security sign off that included MFA to start (so no automation). A different bank bought expensive monitoring tools and then threw a bunch of money at refining the outputs. [0] https://blog.pentesteracademy.com/abusing-sys-module-capability-to-perform-docker-container-breakout-cf5c29956edd?gi=561118cc2eee https://blog.pentesteracademy.com/abusing-sys-module-capabil...

tpetry 6y ago

The problem is adding ONLY the exact files needed is currently impossible when building docker containers. If you are building go/rust executables this easy, you will get one executable you'll add. But if you need to pull in some dependency by a package manager you are lost, they will pull in so many dependencies you may not need but are not defined optional by the packages. A small container is really impossible.

jbverschoor 6y ago
No it's perfectly possible, but people are just lazy and/or don't understand their platforms. Docker is for many a "simple" way of getting their app running, and once it's up, they never look back.
folkrav 6y ago
There are ways, but they aren't particularly obvious and are more work than they should. With some elbow grease involving multi-step builds, snapshots and diffing the resulting images to copy only the required files into your final image, you can definitely build them, at least. It isn't made particular easy for you. Honestly it's actually kind of a pain, wherein lies the problem. Doesn't help that some languages' official images are kind of bloated themselves, either.
- mikeyjk 6y ago
  Is diffing images really necessary? I've done multi step builds in the past for a Java app and I didn't find it especially hard to only include what was required. E.g. the final resultant image would exclude maven, which would be used in the first stage of the build.
  - tpetry 6y ago
    Multi Step Images will not help if you want to build a python container and the package manager will pull in e.b. Bash for the python runtime snd many more depencies. It only saves you from adding build tools to the image.
  - 6y ago