Linux
Welcome to c/linux!
Welcome to our thriving Linux community! Whether you're a seasoned Linux enthusiast or just starting your journey, we're excited to have you here. Explore, learn, and collaborate with like-minded individuals who share a passion for open-source software and the endless possibilities it offers. Together, let's dive into the world of Linux and embrace the power of freedom, customization, and innovation. Enjoy your stay and feel free to join the vibrant discussions that await you!
Rules:
-
Stay on topic: Posts and discussions should be related to Linux, open source software, and related technologies.
-
Be respectful: Treat fellow community members with respect and courtesy.
-
Quality over quantity: Share informative and thought-provoking content.
-
No spam or self-promotion: Avoid excessive self-promotion or spamming.
-
No NSFW adult content
-
Follow general lemmy guidelines.
view the rest of the comments
Distrobox is design to be the opposite of confined. Its goal is integration. The container is stripped away as much as possible to allow for sharing host resources.
As it says on the Distrobox website:
I would also argue calling "plain docker/podman container or a Flatpak" being "highly sandboxed" is also quite wrong and a misuse of those technology.
It uses Docker/Podman which is not a security sandbox. The purpose is app containers, not a security boundary. It shares the sane kernel as the host, which makes kernel vulnerabilities a source of container escapes. Docker (the default) runs as root and could be a source of privilege escalation. Best case is use gVisor or SELinux. Still not a secure sandbox.
Similar problems with Flatpak. Not a secure sandbox. ~~Doesn't~~ Barely filters syscalls (and in a general way instead of per-app), barely reduces attack surface, granting frequently required permissions often significantly reduces the strength of the sandbox, shares a kernel with the host (and no application kernel like gVisor or sydbox), weak use MAC (like SELinux). Most of this can also be said of the previous 2 container software (and also LXC/LXD/Incus).
Also, don't use browsers with Flatpak, they have a significantly weaker sandbox because it is missing a layer of sandboxing (namespaces). This makes attack exponential more likely by reducing the need chain another major vulnerability to execute a successful sandbox break.
What you want is a VM. It is designed to be a secure sandbox but needs some configuring.
Flatpak sandboxing uses bubblewrap, which uses seccomp and can filter syscalls.
LXD/Incus can run qemu-kvm virtual machines in addition to containers. In fact, I like the security posture of LXD/Incus better here because they use cgroups, namespaces, seccomp, to sandbox the qemu process, which libvirt also does but proxmox does not.
Yes, I understand Flatpak does some seccomp syscall filtering. It still isn't enough to consider a secure sandbox where the threat model is that the app is untrusted. Bubblewrap is generally considered a weak sandbox and isn't "secure by default", allowing for easy footguns.
LXC/Incus does support proper VMs but it isnt as common.
Neither are really designed to run untrusted apps.
~~LXC is namespaces only, maybe you're thinking of libvirt~~ I stand corrected about LXD, never knew it did that, weird I don't know why you'd wanna do that instead of using libvirt.
Flatpack uses namespaces. And unless you have it disabled in the kernel, namespaces can be nested. There's nothing stopping a browser running a flatpack from using namespaces itself.
Not to say that you are incorrect about namespaces vs security. Namespaces are not as secure as a VM.
Flatpakbapps cant use namespaces. Flatpak (the software) uses namespaces but Flatpak apps can not.
Thanks for your reply. The point here is not about the merits of distrobox for security. This is a constraint that is not easily changed. It is only an element present, not an implementation of sandboxing.
I am looking for the best method that is hopefully less complicated than a systemwide SELinux policy plus Pam and Groups.
If anything, the distrobox is an added issue due to the nobody user.
I guess I just don't understand your question. Explain in more detail.
Really think about the Ws (who, what, where, when, how).
If you want to protect against an "advanced" threat actor, you can not do that without multiple layers of isolation, including but not limited to virtualization, MAC (SELinux), namespaces, seccomp.
All protections are meaningless without a clear understanding of what assets you are protecting, the threat you face, and they want from you.