Comment

I never said it was trivial to escape, I just said it wasn’t a strong security boundary. Nothing is black and white. Docker isn’t going to stop a resourceful attacker but you may not need to worry about attackers who are going to spend >$100k on a 0-day vulnerability.

The Linux kernel isn’t easy to exploit as if it was it wouldn’t be used so heavily in security sensitive environments

If any “security sensitive” environment is relying on Linux kernel isolation I don’t think they are taking their sensitivity very seriously. The most security sensitive environments I am aware of doing this are shared hosting providers. Personally I wouldn’t rely on them to host anything particularly sensitive. But everyone’s risk tolerance is different.

use podman with a dedicated user for sandboxing

This is only every so slightly better. Users have existed in the kernel for a very long time so may be harder to find bugs in but at the end of the day the Linux kernel is just too complex to provide strong isolation.

There isn’t any way to break out of a properly configured docker container right now but if there were it would mean that an attacker has root

I would bet $1k that within 5 years we find out that this is false. Obviously all of the publicly known vulnerabilities have been patched. But more are found all of the time. For hobbyist use this is probably fine, but you should acknowledge the risk. There are almost certainly full kernel-privilege code execution vulnerabilities in the current Linux kernel, and it is very likely that at least one of these is privately known.

source

Sort:hotnew top

possiblylinux127@lemmy.zip ⁨6⁩ ⁨months⁩ ago
I think speculation is generally a bad security practice. What you need is least privilege and security in depth. At some point you need to trust something somewhere. Kernel level exploits are very rare

source
- Lemongrab@lemmy.one ⁨6⁩ ⁨months⁩ ago
  It is not speculation, it is reducing attack surface. Security is preemptive. Docker/Podman are not strong isolation solutions. Rare does not mean we shouldn’t protect against the chance of kernel vulnerabilities. The linux kernel around 30 million lines of code long and written in a memory unsafe language. Code isn’t safe just because we dont know the vulnerabilities, this is basic cybersec reasoning.
  
  source
  - possiblylinux127@lemmy.zip ⁨6⁩ ⁨months⁩ ago
    Write me an exploit then
    
    If it so insecure prove it
    
    source
    Lemongrab@lemmy.one ⁨6⁩ ⁨months⁩ ago
    That is not how security works. You must protect against known and unknown attack vectors. I am only pointing out weaknesses of Docker and other linux containers that share the kernel with the host or/and run with Root. I’m not saying anything original or crazy, just read up on the security of these technologies and their limits. I am not a malware designer, I am a security researcher.
    
    Look into gVisor and Kara Containers for info on how to improve the security of containers.
    
    Here are some readings for you:
    
    …tux.pizza/…/help_can_i_safely_run_malware_inside…
    csoonline.com/…/vulnerabilities-in-docker-other-c…
    www.panoptica.app/…/7-ways-to-escape-a-container
    blog.trailofbits.com/…/understanding-docker-conta…
    securityweek.com/leaky-vessels-container-escape-v…
    cybereason.com/…/container-escape-all-you-need-is…
    
    source
- kevincox@lemmy.ml ⁨6⁩ ⁨months⁩ ago
  I think assuming that you are safe because you aren’t aware of any vulnerabilities is bad security practice.
  
  Minimizing your attack surface is critical. Defense in depth is just one way to minimize your attack surface (but a very effective one). Putting your container inside a VM is excellent defense in depth. Putting your container inside a non-root user barely is because you still have one Linux kernel sized hole in your swiss-cheese defence model.
  
  source
  - possiblylinux127@lemmy.zip ⁨6⁩ ⁨months⁩ ago
    How is the Linux kernel more insecure than anything else? It isn’t this massive gapping hole like you make it sound. In 20 years how many serious organization destroying vulnerabilities have there been? It is pretty solid.
    
    I guess we should all use whatever proprietary software thing you think is best
    
    source
    kevincox@lemmy.ml ⁨6⁩ ⁨months⁩ ago
    The Linux kernel is less secure for running untrusted software than a VM because most hypervisors have a far smaller attack surface.
    
    how many serious organization destroying vulnerabilities have there been? It is pretty solid.
    
    The CVEs differ? The reasons that most organizations don’t get destroyed is that they don’t run untrusted software on the same kernels that process their sensitive information.
    
    whatever proprietary software thing you think is best
    
    This is a ridiculous attack. I never suggested anything about proprietary software. Linux’s KVM is pretty great.
    
    source
loudwhisper@infosec.pub ⁨6⁩ ⁨months⁩ ago
Also hypervisors get escape vulnerabilities every now and then. I would say that in a realistic scale of difficulty of escape, a good container (doesn’t matter if using Docker or something else) is a good security boundary.

If this is not the case, I wonder what your scale extremes are.

A good container has very little attack surface, since it can have almost no code or tools available, a read-only fs, no user privileges or capabilities whatsoever and possibly even a syscall filter. Sure, the kernel is the same but then the only alternative is to split that per application VMs-like) and you move the problem to hypervisors.

In the context of this asked question, I think the gains from reducing the attack surface are completely outweighed from the loss in functionality and waste of resources.

source