Also, Chromebooks use LXC containers, so it’s possible change Google provided Debian LXC container to newest Ubuntu container (or any other distro) and have that installed Linux GUI app at ChromeOS desktop menus, like Gimp etc:
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).
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.
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