6 ms·

Looks like the page is down unfortunately. I've seen headlines like this before, but at the time a lot of the vulnerabilities were in packages that were instal

Looks like the page is down unfortunately. I've seen headlines like this before, but at the time a lot of the vulnerabilities were in packages that were installed on the image but were not launched, or generally not exposed. I do wish for an easy way to frequently update images though (i.e. rebuilding them from scratch installing the latest packages). It's often hard to determine what you're including in your container.

Quiark 6y ago
Exactly, many of these reports are of the kind "your java Web app container has a priv esc vuln in sudo" which is irrelevant 95% of the time. Need some smart tooling to help comb through all that noise.
- ktpsns 6y ago
  I don't second that. If the java web app also has some privilege escalation, this allows somebody to overtake not only the container as root, but, given how Docker works, also to overtake the docker host as root! Security matters, even if it is apparently about unused parts in a complex system.
  - znpy 6y ago
    > if the java web app also has some privilege escalation If.
    - ktpsns 6y ago
      Of course "if": That's how security works. The most trivial mistakes are still made in 2020, such as SQL injections. Many people write horribly insecure code, because they were never trained on a security-oriented focus. Story Time: At a customer I've once seen all (web) applications in their docker containerr running with root permissions. I raised an issue but the devops told me this would be fine. They simply did not care about security. They run all their containers on two rented VPS. They dockerized everything, also their mail infrastructure, etc.. This means: If anybody found the easiest remote code execution bug in their webpages, they immediately could take over the whole fucking company. Because root in docker = root on the whole machine. Think about that twice.
plasticxme 6y ago
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
syberspace 6y ago
if they were not launched why are they in the image to begin with?
IngoBlechschmid 6y ago
For that I reason, I typically create my Docker images using Nix. This has been discussed here before a couple of times, for instance at https://news.ycombinator.com/item?id=22295102 https://news.ycombinator.com/item?id=22295102. :-)

Quiark 6y ago

Exactly, many of these reports are of the kind "your java Web app container has a priv esc vuln in sudo" which is irrelevant 95% of the time. Need some smart tooling to help comb through all that noise.

ktpsns 6y ago
I don't second that. If the java web app also has some privilege escalation, this allows somebody to overtake not only the container as root, but, given how Docker works, also to overtake the docker host as root! Security matters, even if it is apparently about unused parts in a complex system.
- znpy 6y ago
  > if the java web app also has some privilege escalation If.
  - ktpsns 6y ago
    Of course "if": That's how security works. The most trivial mistakes are still made in 2020, such as SQL injections. Many people write horribly insecure code, because they were never trained on a security-oriented focus. Story Time: At a customer I've once seen all (web) applications in their docker containerr running with root permissions. I raised an issue but the devops told me this would be fine. They simply did not care about security. They run all their containers on two rented VPS. They dockerized everything, also their mail infrastructure, etc.. This means: If anybody found the easiest remote code execution bug in their webpages, they immediately could take over the whole fucking company. Because root in docker = root on the whole machine. Think about that twice.

plasticxme 6y ago

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

syberspace 6y ago

if they were not launched why are they in the image to begin with?

IngoBlechschmid 6y ago

For that I reason, I typically create my Docker images using Nix. This has been discussed here before a couple of times, for instance at https://news.ycombinator.com/item?id=22295102 https://news.ycombinator.com/item?id=22295102. :-)