Thanks for the comments @sergiusens and @picchietti! Just to pick up on a few points.
As an anecdote, earlier today I realized that I need to install one of our snaps on an AMD64 machine…but so far we’d only built and deployed it to ARM, so there was no AMD64 version available. I pulled up snapcraft.yaml in the GitHub repo, added a - build-on: amd64 line to the architectures section, committed, and about 10 minutes later the AMD64 snap was released. That was pretty neat!
Good question. More so than new features, from my perspective there is some room to improve the reliability (/ensure there are no bugs). Every once in a while I seem to run into glitches - whether inherent to snapcraft itself or the CI build system - and tackling these can be a real time-sink. I felt that the upgrades to v7 (and core22) introduced a few issues in particular (e.g. this)…maybe it wasn’t quite ready for prime time.
We actually pretty much exclusively use GitHub+Launchpad CI for builds. It also makes it easier to collaborate with other team members, as not everyone has a build-ready RPi ready to go. The main reason for occasionally doing local builds is to test major changes, since it’s easier to troubleshoot and iterate locally. But yeah, 99% of the time the CI builds work great!
That’s true. My point is that this confinement guards against a class of vulnerabilities that - while hypothetically exists - is not actually common in the real world. I.e., it seems quite rare for hackers/exploits to try to remotely modify the OS or install software. Perhaps because that’s harder to do (at scale) anyway, while not being that beneficial.
This is subjective of course - and I can’t pretend to have done a comprehensive study on the topic. But if were to take a seemingly representative list like https://www.iotforall.com/5-worst-iot-hacking-vulnerabilities, or OWASP’s top-10, none of these are things where sandboxing would really make a difference.
To be clear, Ubuntu Core does have important security features that counter common IoT vulnerabilities: automatic updates, update verification, no default credentials. But I’m not convinced that strict confinement adds much in that regard.
Again, this is fairly subjective, and I welcome indications to the contrary. Also probably a whole separate topic in itself…
Interesting point - I haven’t. From what I understand the idea there is to speed up decompression (and app start-up times), at the expense of a larger snap size. So at first glance it doesn’t seem like something that would help here.
Yeah, I should definitely look into that further! That option wasn’t around until relatively recently…so over time we set up other mechanisms to control updates (like a read-only root) - but those have still not been ideal. So I agree that simply adopting some sort of hold pattern is likely to be a more elegant overall solution, which we should investigate!
Thank you again for the thoughtful comments and input.