Unprivileged LXC -- opinions?
 

Hi all.

Back to Slackware after a prolonged absence. Health issues -- my own and serious illnesses among family members too. Still affecting us all but life must go on.

I'm about to get a VPS and I'm in two minds whether to install NetBSD 10 with Xen or Slackware 15 with unprivileged containers. I don't have any experience with the latter. Is it secure? Stable? Space constraints on the server make LXC more attractive, since I wouldn't have to second guess how much space to assign, as I would with full-blown virtual machines like Xen. And as far as I can tell the containers run fully unprivileged in $HOME. Thanks by the way to Chris Willing for the great instructions and information covering all this.

I would prefer also to connect a dummy network interface on the host to the bridge instead of connecting the physical interface. My memory is a bit rusty here, and it seems Slackware has a way of setting up a bridge in rc.inet now. Is tun/tap still the way to set up virtual or dummy interfaces? Obviously I would enable routing to the external interface. I would also firewall on the external interface. Don't ask why : I just never liked bridging the physical interface.

Last but not least, I hope to encrypt all but the boot partition. The host, that is ; I won't be encrypting guests. The VPS host provider tells me their machines are BIOS boot, so I don't anticipate too many problems. Thanks to those involved for the excellent write up on LUKS + LVM too.

I'm looking forward to doing this. It's a small project, 90 percent for personal use but there will eventually be a container serving web content for my brother. So security and stability are vital.

Looking forward to your views and opinions.

Containers do have more interesting flaws than KVM accelerated VMs. Both are secure for casual use and insecure if security is to be considered.

I use both qemu and apptainer. With qemu it is not strictly necessary to preallocate disk space. The 9p shared directory could be used for both /home and the operating system.

Qemu has optimized shared directory that approaches memory bandwidth, contrast to the shared folder of VirtualBox, which descended its code from ancient versions of qemu and is ten times slower.

Interesting. I hadn't heard of either apptainer or 9p. I wonder why apptainer isn't as well-known as Docker.

Curious to know what the flaws in LXC might be. I have read that LXC is not as secure or stable as full-blown virtualisation, but I imagine that's down to the likes of Debian, Ubuntu and Fedora making their own "improvements" to upstream. I imagine that isn't true of Slackware.

I've been using LXC unprivileged containers for years with no issues, with non-Slack distros.
LXC handles all the network/bridge setup. If you want to run non-Slack(systemd) distros with networking that starts with the container, you'll need patches to rc.elogind, and some additional scripts.

Apptainer was renamed from "singularity" only recently while joining the Linux Foundation:
https://www.linuxfoundation.org/pres...g-environments

LXC/Apptainer/Docker etc. lightweight virtual machines (or containers) and the host environment share the same kernel. Hardware flaws related to protected mode and kernel software flaws are vulnerable.

For a guest machine to break qemu-kvm, it is usually necessary to take advantage of hardware flaws before the host is exposed, such as hardware flaws like Zenbleed, Spectre, and those related to hardware virtualization. I'd say usually because in the cases where, for example, guest data goes through VFS of the host, host filesystem bugs are vulnerable. Another example is the guest stalling the SLUB of the host on machines with large memory (Slackware defaults to SLUB instead of SLAB).

Seriously, I'm not security expert so I might well be wrong.

Good to know. I don't think I'll be running systemd distros, although I might run a kvm NetBSD guest in parallel, which I think is possible.