There I was. Bitcoin core is not being maintained via the ppa any more…and not a package.
I decide to install a snap.
I decide to backup a wallet.
I search finally figuring out that common is what I am looking for. I find out that directory access is hard coded. I see that the software is basically jailed. I see that symlinks do not work.
I am speechless, and in awe of what is going on here.
This project has such great potential, but I feel like if I keep using its derivatives I will convert to the dark side.
You’re clearly technically adept, so hyperbole, faux amazement and thinly veiled threats aside, what specifically did you try which didn’t work? What steps can someone else take to reproduce the issue you’ve had with this snap?
I get it, you have to go through software modification to make it work. Etc.
So the question I have then:
How did a package manager evolve to also take on application security, and why does this decision stand? I just want to understand what I am missing here.
Short question with a long answer.
Snaps initially were developed in a culture where traditional packaging systems had zero separation. Installing a deb means the maintainer of the deb has root on your machine. So any rando package a user installs could leak your ssh, gpg or bitcoin wallet. The goal is to make an easy to use system for packaging applications with fast delivery and easy of installation / removal for users. Automatic updates and fast turn around for developers mean users get updates quickly. Just like on Android where nobody knows or cares what version of Spotify they have, they just know they have the latest. We brought that to the IoT, Linux Server and desktop space.
I would argue that security has been an important part of package managers on Linux for almost as long as there have been package managers.
Take the apt package manager found on Ubuntu and Debian: in its default configuration, it will only install packages from an archive whose index has been cryptographically signed by a key pre-loaded onto the system at install. The only way for packages to be added to that archive is after review by a package maintainer (which includes explicit security reviews for packages promoted to main).
This is great if everything you want to run is included in the archive. That’s clearly not the case for all users though: they might want software that the distro maintainers don’t have time to package, or require newer versions than what is included in the distro.
PPAs were the first attempt to solve this on Ubuntu, by providing a way for developers to produce overlays for the main Ubuntu archive. Unfortunately, they result in a significant drop in security of the system:
In addition to adding new packages, a PPA can replace any package in the Ubuntu archive. This isn’t necessarily malicious, but can easily destabilise the system.
A PPA maintainer won’t necessarily follow the same security and quality guidelines as the Ubuntu developers.
The user makes a one-off decision to trust the PPA, and then automatically trusts all new packages added to that PPA. There is no obvious warning if the PPA suddenly starts providing a libc6 package that shadows the main archive, for instance.
Snaps are an attempt to solve similar problems without the security drawbacks. The confinement system prevents snaps from interfering with the base system and limit the access to user data, so the user does not need to place as much trust in the developer/packager. When the user installs a snap, they can be sure that any updates to the snap come from the same publisher: you don’t need to worry that installing a snap foo will change how a snap bar is updated.
While this is indeed true, one needs to keep in mind that dpkg runs as root and that deb packages can have maintainer scripts included that get executed at package install time as root …
Inside such maintainer scripts the person owning the PPA can pretty much do anything to the users system (install a keylogger to capture home banking password input, put some script in place to send all password databases on the system to a server, hook you up to a botnet etc etc)
So in conclusion PPAs require really a lot of (blind) trust that the PPA owner does not do anything of the above, unless you are capable and willing to inspecting all the source code inside such a PPA.
The confinement of snap packages makes such a scenario impossible …
Sure: my point was that on a default install (i.e. no PPAs or other external repositories configured), the only maintainer scripts running as root are ones written or vetted by Ubuntu developers. I agree that that security breaks down once you introduce PPAs or external repositories: anything can happen at that point.
I see snaps as a solution to many of the same problems that prompt users to add PPAs to their system, but without compromising security.
From my personal experience, Ubuntu has become a lot more stable since I stopped using so many ppa’s.
The worst a broken snap package can do is crash itself. A broken ppa can take down your whole system and make it unbootable. Moreover, when you remove the snap, you are sure that everything is gone. However, because ppa’s can change anything on your system, you’re never sure that removing the ppa will undo everything it did.
Both these things require snap packages to be confined, because otherwise, you have to trust the publisher “not to do something stupid/dangerous” in their package.
While I agree with pretty much everything wrote here, the big problem I see here is the lack of configurability on the system that protects someone using a snap.
If I want to give software access to the / of my system, and have it delete everything…I should be able to do it.
This freedom seems missing, and I still think it needs to be fixed.
For instance, I was going to do some bitcoin development, and wanted bitcoin-core installed. Now it seems like I have to jump through hoops for file access etc etc
Now that I understand what you are trying to do here, why are these configuration freedoms not inside the software?
This is incorrect, installing a snap with --classic only allows the snap to be installed if it is a classic snap, it does not put a strict snap into classic confinement.
