this post was submitted on 23 Mar 2026
4 points (75.0% liked)

Linux

16754 readers
143 users here now

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:

  1. Stay on topic: Posts and discussions should be related to Linux, open source software, and related technologies.

  2. Be respectful: Treat fellow community members with respect and courtesy.

  3. Quality over quantity: Share informative and thought-provoking content.

  4. No spam or self-promotion: Avoid excessive self-promotion or spamming.

  5. No NSFW adult content

  6. Follow general lemmy guidelines.

founded 2 years ago
MODERATORS
MigratingtoLemmy@lemmy.world
4
How to confine an existing distrobox container? (lemmy.world)
submitted 6 hours ago by j4k3@lemmy.world to c/linux@lemmy.world
7 comments fedilink hide all child comments
 

The container runs a local host server for use in a browser and is untrusted for development reasons. It needs to be treated as an advanced black hat. Its primary goal is recon and sending critical information via advanced connectionless protocols of unknown type. While extremely unlikely, it should be assumed to have access to proprietary systems and keys such as Intel ME and a UEFI shim of some sort. It may also use an otherwise trusted connection such as common git host, CDN, or DNS to communicate. It tries to access everything possible, key logger, desktop GUI, kernel logs, everything.

What is the Occam's Razor of solutions that best fit the constraints in your opinion? Other than the current solution of air gap.

you are viewing a single comment's thread
view the rest of the comments
[–] moonpiedumplings@programming.dev 1 points 2 hours ago (1 children)

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.

[–] Neptr@lemmy.blahaj.zone 1 points 1 hour ago (1 children)

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.

[–] wildbus8979@sh.itjust.works 1 points 35 minutes ago* (last edited 33 minutes ago)

~~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.