4 ms·

There is an addendum at the bottom where they admit the page corruption is still problematic even with rootless podman. Although using this to justify their mi

There is an addendum at the bottom where they admit the page corruption is still problematic even with rootless podman. Although using this to justify their migration to micro-VMs is very strange to me. Sure for this CVE it would have been better, but surely for a future attack it could hit a component shared across VMs but not containers? Are people really choosing technology based on CVE-of-the-week?

anygivnthursday 5mo ago
Containers were never a security boundary. VMs have better isolation, which is why people choose them for security. Containers are convenience and usually have better performance.
- ButlerianJihad 5mo ago
  Containers are a convenience boundary and they increase complexity of your risk assessments. It is easy for security scanners to scan a Linux system, but will they inspect your containers, and snaps, and flatpaks, and VMs? It is easy for DevOps to ssh into your Linux server, but can they also get logged in to each container, and do useful things? Your patches and all dependencies are up-to-date on your server, but those containers are still dragging around legacy dependencies, by design. Is your backup system aware of containers and capable of creating backup images or files, that are suitable for restoring back to service?
  - necovek 5mo ago
    Security scanners already support most container and VM image formats in widespread use. Does this increase complexity? Yes, it does. Is it worth the cost? Depends on each individual case IMO.
    - firesteelrain 5mo ago
      You need a tool like Anchore and PrismaCloud to scan the container images then monitor them in runtime with PrismaCloud. Trellix can “scan” however most people turn off or exclude container directories on the host because it can interfere with the running container.
    - throw0101c 5mo ago
      > Security scanners already support most container and VM image formats in widespread use. E.g., > Container Security stores and scans container images as the images are built, before production. It provides vulnerability and malware detection, along with continuous monitoring of container images. By integrating with the continuous integration and continuous deployment (CI/CD) systems that build container images, Container Security ensures every container reaching production is secure and compliant with enterprise policy. * https://docs.tenable.com/enclave-security/container-security/1_8/Content/welcome.htm https://docs.tenable.com/enclave-security/container-security...
- dwroberts 5mo ago
  I see the ‘not a security boundary’ thing repeated constantly, and while it makes sense (eg. they’re sharing the underlying kernel or at least some access to it) if you think about it a little more, VMs are not magically different: they are better isolated, but VMs on the same host still share the host in common. A CVE next week that allows corruption of host state that affects eg every VM under a particular hypervisor will be no less damaging than this CVE is to containers
  - necovek 5mo ago
    You are obviously right that these are similar in principle: VM isolation exploit would lead to the same exposure like container-related isolation exploits. VMs are considered vastly better because the surface area where exploits can happen is smaller and/or better isolated within the kernel. If you are arguing the latter is not true — and we are all collectively hand-waving away big chunk of the surface area so that may be the case — it would help to be explicit in why you believe an exploit in that area is similarly likely?
    - robertlagrant 5mo ago
      I would say it's the fact that "not a security boundary" appears to be a pass/fail statement, whereas the reality is more like a security continuum, along which VMs are further than containers.
      - necovek 5mo ago
        I believe that is tautologically true, and thus not a very useful framing. Security is obviously a continuum (eg. you can even have a bug in your IPMI FW, and a network packet could break in without any interaction with the OS; or there could be a HW bug too), but there is a discrete "jump" between containers and VMs to the extent that it is useful to call one a security boundary and the other not. Just like a firewall is a security boundary even if it can have security bugs. Whether this jump between exploitable surface area warrants this distinction is what the point is: many believe it does.
      - 5mo ago
- graemep 5mo ago
  They may not provide isolation as VMs but they clearly do limit some attacks. VMs do not provide the same isolation as using physically separate hardware either. I would have thought they provide better isolation than using multiple users which is the traditional security boundary. It might depends on what you mean by a container? Are sandboxes such as Bubblewrap and Firejail containers?
  - anygivnthursday 5mo ago
    > It might depends on what you mean by a container? The article was about Podman and Linux namespaces
    - graemep 5mo ago
      I understood the comment I replied to (and many similar comments that are regularly made on HN) as talking about containers in general. Namespaces are used as a security mechanism.
staticassertion 5mo ago
These sorts of vulns are extremely common on Linux. This one is making the rounds for various reasons but it's a good justification for a migration away from containers if your threat model is concerned about it. MicroVMs have much lower attack surface and you can even toss a container into one if you'd like. Or use gvisor, which mitigates this vulnerability.
- deleted 5mo ago
  [deleted]

anygivnthursday 5mo ago

Containers were never a security boundary. VMs have better isolation, which is why people choose them for security. Containers are convenience and usually have better performance.

ButlerianJihad 5mo ago
Containers are a convenience boundary and they increase complexity of your risk assessments. It is easy for security scanners to scan a Linux system, but will they inspect your containers, and snaps, and flatpaks, and VMs? It is easy for DevOps to ssh into your Linux server, but can they also get logged in to each container, and do useful things? Your patches and all dependencies are up-to-date on your server, but those containers are still dragging around legacy dependencies, by design. Is your backup system aware of containers and capable of creating backup images or files, that are suitable for restoring back to service?
- necovek 5mo ago
  Security scanners already support most container and VM image formats in widespread use. Does this increase complexity? Yes, it does. Is it worth the cost? Depends on each individual case IMO.
  - firesteelrain 5mo ago
    You need a tool like Anchore and PrismaCloud to scan the container images then monitor them in runtime with PrismaCloud. Trellix can “scan” however most people turn off or exclude container directories on the host because it can interfere with the running container.
  - throw0101c 5mo ago
    > Security scanners already support most container and VM image formats in widespread use. E.g., > Container Security stores and scans container images as the images are built, before production. It provides vulnerability and malware detection, along with continuous monitoring of container images. By integrating with the continuous integration and continuous deployment (CI/CD) systems that build container images, Container Security ensures every container reaching production is secure and compliant with enterprise policy. * https://docs.tenable.com/enclave-security/container-security/1_8/Content/welcome.htm https://docs.tenable.com/enclave-security/container-security...
dwroberts 5mo ago
I see the ‘not a security boundary’ thing repeated constantly, and while it makes sense (eg. they’re sharing the underlying kernel or at least some access to it) if you think about it a little more, VMs are not magically different: they are better isolated, but VMs on the same host still share the host in common. A CVE next week that allows corruption of host state that affects eg every VM under a particular hypervisor will be no less damaging than this CVE is to containers
- necovek 5mo ago
  You are obviously right that these are similar in principle: VM isolation exploit would lead to the same exposure like container-related isolation exploits. VMs are considered vastly better because the surface area where exploits can happen is smaller and/or better isolated within the kernel. If you are arguing the latter is not true — and we are all collectively hand-waving away big chunk of the surface area so that may be the case — it would help to be explicit in why you believe an exploit in that area is similarly likely?
  - robertlagrant 5mo ago
    I would say it's the fact that "not a security boundary" appears to be a pass/fail statement, whereas the reality is more like a security continuum, along which VMs are further than containers.
    - necovek 5mo ago
      I believe that is tautologically true, and thus not a very useful framing. Security is obviously a continuum (eg. you can even have a bug in your IPMI FW, and a network packet could break in without any interaction with the OS; or there could be a HW bug too), but there is a discrete "jump" between containers and VMs to the extent that it is useful to call one a security boundary and the other not. Just like a firewall is a security boundary even if it can have security bugs. Whether this jump between exploitable surface area warrants this distinction is what the point is: many believe it does.
    - 5mo ago
graemep 5mo ago
They may not provide isolation as VMs but they clearly do limit some attacks. VMs do not provide the same isolation as using physically separate hardware either. I would have thought they provide better isolation than using multiple users which is the traditional security boundary. It might depends on what you mean by a container? Are sandboxes such as Bubblewrap and Firejail containers?
- anygivnthursday 5mo ago
  > It might depends on what you mean by a container? The article was about Podman and Linux namespaces
  - graemep 5mo ago
    I understood the comment I replied to (and many similar comments that are regularly made on HN) as talking about containers in general. Namespaces are used as a security mechanism.

staticassertion 5mo ago

These sorts of vulns are extremely common on Linux. This one is making the rounds for various reasons but it's a good justification for a migration away from containers if your threat model is concerned about it. MicroVMs have much lower attack surface and you can even toss a container into one if you'd like. Or use gvisor, which mitigates this vulnerability.

deleted 5mo ago
[deleted]