There have been multiple accounts created with the sole purpose of posting advertisement posts or replies containing unsolicited advertising.

Accounts which solely post advertisements, or persistently post them may be terminated.

j4k3 ,
@j4k3@lemmy.world avatar

Everything I run is behind a whitelist firewall on an external device largely for this reason, but also learning curiosity.

Lemongrab ,

Idk how to decide what is safe or not, but as a warning, Docker containers can escape trivially and have access to the kernel.

just_another_person ,

This is not true. Perhaps on an already at-risk or exploitable machine, but even then it’s not trivial, and this is not a widespread thing that happens everywhere all the time

kevincox ,
@kevincox@lemmy.ml avatar

It is. Privilege escalation vulnerabilities are common. There is basically a 100% chance of unpatched container escapes in the Linux kernel. Some of these are very likely privately known and available for sale. So even if you are fully patched a resourceful attacker will escape the container.

That being said if you are a low-value regular-joe patching regularly, the risk is relatively low.

verstra ,

Can you expand on this wild claim? The whole point of containers is isolation so what you are saying is that containers fail at that all the time?

asap ,
@asap@lemmy.world avatar

They might be talking about posts like this (which I would love to have refuted, as this kind of info has so far kept me from using Docker significantly):

security.stackexchange.com/a/169649

just_another_person , (edited )

Containers are isolated from the host by default. If you give a container a mount, it can only interact with the mount, but not the running host. If you further isolated and protected that mount, you would have been fine. Since you ran it as your unprivileged user, it’s one step safer from being able to hijack other parts of the machine, and if it was a “virus”, all it could do is write files to the mount and fill up your disk I guess, or drop a binary and hope you execute it.

asap , (edited )
@asap@lemmy.world avatar

Containers are isolated from the host by default.

Are you certain about that? My understanding is that Docker containers are literally just processes running on the host (ideally rootless), but with no isolation in the way that VMs are isolated from the host.

If you have some links for further reading it would be great, as I have been extremely cautious with my Docker usage so far.

I haven’t found anything to refute this, but this post from 2017 states:

In 2017 alone, 434 linux kernel exploits were found, and as you have seen in this post, kernel exploits can be devastating for containerized environments. This is because containers share the same kernel as the host, thus trusting the built-in protection mechanisms alone isn’t sufficient.

If someone exploits a kernel bug inside a container, they exploited it on the host OS. If this exploit allows for code execution, it will be executed on the host OS, not inside the container.

If this exploit allows for arbitrary memory access, the attacker can change or read any data for any other container.

possiblylinux127 ,

The Linux kernel recently became a CVE numbering authority. That means that there are now tons of CVEs coming out but the overwhelming majority aren’t easily exploitable. They can be rated pretty high with no actual impact. Furthermore, a lot of them require a very specific setup with specific kernel components. It is best to look at the exploitablity score and the recommended CISA actions.

kevincox ,
@kevincox@lemmy.ml avatar

Docker (and Linux containers in general) are not a strong security boundary.

The reason is simply that the Linux kernel is far too large and complex of an interface to be vulnerability free. There are regular privilege escalation and container escapes found. There are also frequent Docker-specific container escape vulnerabilities.

If you want strong security boundaries you should use a VM, or even better separate hardware. This is why cloud container services run containers from different clients in different VMs, containers are not good enough to isolate untrusted workloads.

if Gossa were to be a virus, would I have been infected?

I would assume yes. This would require the virus to know an unpatched exploit for Linux or Docker, but these frequently appear. There are likely many for sale right now. If you aren’t a high value target and your OS is fully patched then someone probably won’t burn an exploit on you, but it is entirely possible.

possiblylinux127 ,

While docker isn’t perfect saying it is completely insecure is untrue. It is true serious vulnerabilities popup once and a while but to say that it is trivial to escape a container is to big of a statement to be true. You can misconfigure a docker container which would allow for an escape but that’s about it for the most part. The Linux kernel isn’t easy to exploit as if it was it wouldn’t be used so heavily in security sensitive environments.

For added security you could use podman with a dedicated user for sandboxing. If the podman container is breached it will have little place to go. Also Podman tends to have better isolation in general. 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

kevincox ,
@kevincox@lemmy.ml avatar

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.

possiblylinux127 ,

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

kevincox ,
@kevincox@lemmy.ml avatar

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.

possiblylinux127 ,

Podman

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • [email protected]
  • random
  • lifeLocal
  • goranko
  • All magazines
    •