A detail step to run desktop environment in container

Incus
28

@catfish My idea was to have a minimal host, so no DE and the absolute minimum number of packages. And have workstations and a NAS containerized. Likely all can be unprivileged but why not go privileged and make some shortcuts. No public-facing services or unknown executables so who cares. Handling (ZFS) storage directly in the NAS for example would be more straightforward, as well as things like graphics or sound probably.

@echoslider That’s quite useful, thanks! But you say you have apparmor and SELinux enabled, why do that with unprivileged containers? The images I used so far come with them disabled.

29

As I said before you don’t have to install a compositor on host, just install DE and setup vnc or rdp in CT will be fine.
No, when you can run unprivileged, run unprivileged. Even without public-facing services, you CT still connects to internet. As long as anything connects to internet, it can be hacked. It better to lower attacking surface.
About storage, sadly, you can’t add block device to CT, as it said: How to manage storage volumes - Incus documentation. And I don’t think it will fit your need: Type: disk - Incus documentation
I don’t know how to manage graphics or sound in CT, no document about it, so I can’t help about that.

30

I didn’t write about wanting to add compositor, you must have misread something.

Use the security you need, not more. That’s my approach here. If it’s as secure as a non-virtualized system with similar setup that’s fine.

31

The “NAS container” might indeed be a far strech, but I want to test it out. How far incus based storage management can go or, on the other hand, how responsibilities could be split between host and guest in this regard.

32

There is also XPRA which can be nice if you manage to set it up.

1 Like
33

@pycaw So I was originally writing a response to one of your comments but I kind of spiralled into responding to multiple of your comments instead. Here’s a bit of an essay addressing some of the points you made.

From: A detail step to run desktop environment in container - #28 by pycaw

Likely all can be unprivileged but why not go privileged and make some shortcuts.

There aren’t any shortcuts. There isn’t a benefit because enabling security.priviledged, it just sets CT UID=0 == Host UID=0 [1]. Additionally, Incus expects an empty /dev in base images and automatically creates the device nodes listed in [2]. So you’d need to passthrough /dev/dri/card* into the instance regardless.

[1] About security - Incus documentation

[2] Container runtime environment - Incus documentation

Handling (ZFS) storage directly in the NAS for example would be more straightforward, as well as things like graphics or sound probably.

You could but I don’t see any upsides in doing so. You would also likely introduce a potential denial of service (at least for zfs and zpool) due to introducing an impedance mismatch between the DKMS (or akmod) kernel module and the user space utility should they ever be out of sync.

A simpler approach would be to let Incus handling the storage pools and just create a bare instance with a NFS, or Samba, server; this still requires that you install kernel modules on the host at least but those wouldn’t break your ability administer your pool.

Graphics I mentioned earlier (/dev/dri/card*) and audio wouldn’t make too much sense if you are treating it in a remote multi-tenant scenario, remote desktop solutions should have virtual audio devices you can use instead. In a local scenario, it’s possible that you could configure multiple Pipewire sockets to route to different speakers but that isn’t something I’m knowledgeable in.

But you say you have apparmor and SELinux enabled, why do that with unprivileged containers?

Defence in depth. I think @stgraber can say more, but Linux containers (as in cgroups and namespaces) used to be quite vulnerable so it’s safer than not to layer on MAC in the event a new breakout exploit is discovered.

There’s no real disadvantage to keep MAC enabled especially if you’re doing most of your work within instances and not touching the host.

Also note that Incus automatically mounts paths listed in the “Mounts” section of [2] and I quote verbatim: “[the] majority of those paths will not be writable (or even readable) from inside an unprivileged container. In privileged containers, they will be blocked by the AppArmor policy.”

The images I used so far come with them disabled.

MAC is setup on the host, not in containers

From A detail step to run desktop environment in container - #30 by pycaw

I didn’t write about wanting to add compositor, you must have misread something.

I think their interpretation would be you creating GUI instances to use for workstations

–

From A detail step to run desktop environment in container - #31 by pycaw

Absolutely don’t give up on the idea, give it a shot and see what sticks. I found this post a while ago, you can try to see if it’ll give you an inspiration: I Built a Home Server | zacksiri.dev. Despite it being written for LXD and having a vague, it should be compatible with Incus and give some ideas as to how to handle serving as a network storage

1 Like
34

On top of what @SirGiggles already wrote, I’ll add:

  1. The benefit of containers is the separation of processes from the host. You want to run some software? Stick it in a container. It’s cheating when you use security.privileged when it is not 100% required.
  2. You can run GUI apps in a container and get them to appear on the (existing) desktop of the host. Or, you can arrange for the container to have its own desktop environment.
  3. The GUI app can run with either a) no hardware acceleration, b) acceleration, sharing the GPU of the host, or c) full GPU acceleration using a separate GPU dedicated for the container.
  4. A choice between X11 or Wayland.

When discussing about GUI in a container/virtual machine, it’s important to specify which combination (out of twelve combinations) we are looking into.

At some point there will be further automation when creating such containers and virtual machines so that the configuration is done automatically. Until we get there, we can live with semi-automatic list of instructions.

2 Likes
35

You cleared up a number of things. Thank you for the home server link especially! A use case where I thought going raw.idmap 'both 0 0', or privileged, is when wanting to have a directory where both host and the containers think root is doing everything (to facilitate a local RPM repo cache) but idmap shifting should solve this and while it requires an explicit step (and therefore could warrant the alternate approach as being a shortcut) should work outside the box; I’ve yet to test it.

@simos I can’t argue with that. At this point, as largely a noobie, my issue is with semantics/presentation. I still believe use cases where users of the containers can be trusted with full root access on the host are totally realistic for many home lab setups.
(Earlier I mentioned that this use case and the topic of dicussion here are releated to an extent, and that’s how privilege had gotten spotlight.)
All my use cases for the forseeable future are of this kind. The fact that the functioning of unprivileged containers is so developed that there’s barely a need for privileged ones should not label an implementation of this use case, in the event it does rely on privileged ones, as “unsafe”. Or, if that is to be, then don’t say it because it’s possible to exit the isolation (since with this use case preventing that can fall outside the point) but that there are potential vulnerabilities stemming from this form of virtualization itself.

In any case, the message is clear, unprivileged can do it pretty much all, including hosting DE’s. Use it.

36

Wow, I will definitely test this out.

1 Like
37

Forgot to add that x2go offers the similar functionality but i only tried and failed to get these to work on a headless remote server.
Feel free to write down your experiences, probably start a new thread (:

1 Like
38

A bit of a late comment but I did also want to make an addendum to managing ZFS inside a container instance.

ZFS 2.2.0 [1][2] released a while ago with namespace delegation support, this basically means that you can manage a dataset inside the container, using ZFS user space utilities, without worrying about touching other non-related datasets.

You can enable this feature using zfs.delegate [3]

[1] Release zfs-2.2.0 · openzfs/zfs · GitHub
[2] Add Linux namespace delegation support by allanjude · Pull Request #12263 · openzfs/zfs · GitHub
[3] ZFS - zfs - Incus documentation

So while you aren’t administering a pool inside the container, this could give you some more fine grained control with a NAS in Incus setup

1 Like