Right. Sorry, I don’t understand your point. The idea here is that snapd (perhaps through an option) would launch a given snap in a lightweight virtual-machine (for instance firecracker even though it’s just an example of the purpose-driven virtual machine I mean and not an actual possibility at this stage).
I mean, LXC is lightweight virtual machine. It is possible to limit with LXC commands, how much RAM is used per each LXC virtual machine. I do have this currently running on bare metal:
-
Ubuntu Server installed, there webserver installed.
-
LXC containers installed to different internal IP addresses. Each LXC container can have different distro.
-
To LXC containers, Wekan Snap package installed.
-
Webserver proxying different SSL subdomains to different snaps.
Sure all this could be scripted to make it all automatic creating.
For example, compared to Qubes OS, Qubes OS SaltStack scripts are used to build whole internal network environments.
Sorry. No. LXC is containerization. See:
LXD supports the idea of a “system container” in the sense that it uses a root filesystem of its own but most importantly still relies on the host kernel.
LXD at some point added support for managing true virtual machines but that’s really just a management layer on existing tech.
The question is whether you are talking about operating system level virtualization (containers, processes, control groups, etc.) or processor level virtualization.
Most definitions of “virtual machines” mean the latter and that’s the one I mean.
AFAIK all these are similar containerization techniques, limiting resources visible inside container, so code running inside container does not have access to outside, if it’s limited in some way:
-
Snap
-
Docker
-
LXC
-
Firecracker
-
Chroot
-
https://sandstorm.io Grains (although this has addidional feature, grain is only running when someone uses grain).
These do use different tech, like cgroups, or other ways to limit resources, but idea is mostly the same.
There’s an enormous difference between Firecracker and the rest on your list. I would certainly not (and I think most people) consider them to be “similar containerization techniques” when Firecracker isn’t containerization at all.
I wonder if we could use this as a basis:
Of course, Firecracker to my knowledge, has no facility for running a “desktop” application. But I definitely think the microVM pattern should be used on the desktop as well.
If you mean sandboxing desktop app, I think using Firejail makes more sense https://firejail.wordpress.com , to limit directories etc, so that it would be improvement over snap classic.
When it’s Snap strict sandbox like Wekan https://wekan.github.io that is webserver, and does not require desktop access, then maybe firecracker would be an improvement, although I have never read about there being problems with Snap strict sandboxing.
I’m specifically interested in using a microVM concept, like Firecracker, but for desktop applications. I’m not particularly interested in a different type of operating system construct that isn’t backed by hardware. It’s OK if someone else is this thread was just specifically about exploring using VMs.
The security ladder though would generally be like [container] -> [virtual machine] -> [separate hardware].
So if you were aiming for more secure you would pursue VMs (generally speaking, in the abstract). Again, just all opinions and what I was interested in discussing in this thread.
It’s an interesting idea. I’m not sure if it’s been considered, but I think you’ll run into a bunch of problems if you try it.
Sharing the kernel with the host system does present more of an attack surface than a VM, but it also makes a bunch of stuff easier. Particularly: a whole host of infrastructure uses AF_UNIX sockets, file descriptor passing, and shared memory. This works with snapd confinement precisely because the snap shares the host kernel. Each of these is a problem you have to solve - without significant application support - if you want to run snaps in a transparent VM.
That’s a significant amount of work to reduce the attack surface from kernel bugs to hypervisor bugs.
Agreed. I never said it would be easy. But if you look at the state of virtualization on the desktop, at least with qemu, it’s quite impressive. So from that perspective at least I think most of the problems are “solved”. Deep integration would be the biggest issue, I think.
That is true if you are only using strictly confined snaps. The number of classically confined snaps does not appear to be waning or being actively discouraged. So what’s your attack surface for those? 
well, classic snaps are snaps that simply can not be packaged under confinement, even if you’d put their execution into a VM they would still need to have full access to the host, the VM just adds extra overhead for no benefit in that case …
also classic confinement is only allowed for a very limited type of snaps and only to uploaders that would also be granted upload rights for deb packages to a partner archive (upstreams and trusted upstream developers) see the criteria at (see the “supported” list):
I respectively disagree that there would be no benefit. I would rather mediate all access to my host system. That may not be a goal of Canonical’s snapd and running classically confined snaps might be OK for you/them but it’s increasingly NOT OK for me.
The problem is, as is being made painfully clear to all of us on an ongoing basis, is that applications these days are made up of (in some cases) tons and tons of dependencies. So unless all of that code is being constantly audited it has to be assumed to be not safe.
I don’t like it anymore than anyone else because it’s a huge pain. But that’s the reality. So for me, not necessarily anyone else, I am in a position where I am increasingly less likely to use applications, especially those I might like to just “try out”.
I think the security posture of the desktop has to increase 10x from where it is today. It’s a personal, lightly informed opinion and we may differ.
There may be some developments in other areas of application development (WebAssembly runtimes maybe?) that aid in this but if snapd had the option to run applications in microVMs, on the desktop I would love it.
well, i don’t see how the VM improves something like an IDE that by default will need full access to all headers, compilers, libs, linkers and build systems installed on the host … i also fail to see what/how you would confine a terminal emulator more effectively when running inside a VM, both of the above would still need the same access they have without VM to stay functional …
I do get how a VM might help to harden the existing strict snaps but i’m highly doubtful the benefit outweighs the cost when running a whole OS per app and particularly launching that … we already have enough unsolved performance and integration issues in the current model that need solving, adding an additional layer that just eats even more resources will surely not help fixing these …
If it can exist on the host it can almost surely exist on the VM.
Agreed. But what I’m saying is that (and it might just me me) is that I’m tipping toward security instead of performance more and more by the day. If our constant pursuit is performance than it will be at the sacrifice of security.
IMO, this simplifies down to a problem of remote desktop support in VM’s.
Several VM’s already have GPU paravirtualisation, X11 forwarding, Pulseaudio over the network, directory mounting, etc. Even in Windows with WSL2g, all these come as a default offering.
This seems much less a case of “snap needs to learn how to manage VM’s”, and more “VM’s need to learn how to manage snap”. Which would then simplify more generally, how do we configure VM’s to automatically set themselves up (cloud-init & such) and then present it all in a good UI with good UX.
Which IMO means it’s not snapd’s problem but a problem for the VM ecosystem in general.
i don’t really see any sacrifice of security with the current model (in fact quite the opposite), someone has still to show me how to break out of our confinement … which has not happened in 7 years that i work with/on snaps
I’m OK with a difference of opinion. I don’t have a mathematical proof. Oh- but that still doesn’t speak to classically confined snaps.
I don’t necessarily disagree with this characterization. I’ve often wondered why Linux doesn’t have “a per-application” virtualization capability similar to other virtualization solutions that offer a “seamless” mode.
I think if something like that existed it would at least help this situation.
I also wonder if Wayland support generally would help solve this problem (at least from the display side). I also feel like between virgl, Zink and Vulkan are also really positive movements in helping solve that particular aspect of the problem.
Maybe I’m crazy but everything else* outside of sound and graphics are solved for high-performance, server based virtualization.
* for some definitions of "everything else"
Interestingly there could be some prior art / WIP that we could leverage or at least benefit from as a source of knowledge:
https://www.xda-developers.com/microdroid-stripped-down-android-virtual-machines/
and
https://source.android.com/devices/architecture/kernel/generic-kernel-image
and not especially relevant per se but potentially interesting:
https://fuchsia-review.googlesource.com/c/fuchsia/+/485181
I’m starting to ramp up on rust-vmm and related components as a result. Will be fun if nothing else
I also wonder if something like crosvm and virtio-wayland would go a long way to getting me to the goal: