Store Policing


#1

Snapcraft is a rather major departure from other Linux package management - instead of packaging scripts all coming from trusted community members, anyone with a computer is able to upload a package to the snapcraft store. Unlike PPAs or other repos, there is no explicit step where users have to opt into downloading software from an external source (something which users have been pretty well trained to understand opens you up to that software being malicious). Unlike other App Stores (iOS/MacOS/Android/Windows, I assume), my understanding is there is no review process during the upload to filter out packages which are malware/malicious/namesquatting/spyware/etc. While the sandboxing aspect of snaps helps reduce the exposure users have to this (is sandboxing required on store-uploaded snaps?), this obviously doesn’t prevent all types of attacks, nor against attacks where the snap itself misbehaves.

This model is especially damaging in the cryptocurrency space, where users install cryptocurrency wallets in order to hold their funds, and if those apps are malicious they can trivially walk away with those funds. We recently discovered a third-party was uploading packages for various Bitcoin wallets at https://bugs.launchpad.net/snapstore/+bug/1803914 (which, while that third-party appeared to have Bitcoin-political motivations, was not, apparently, stealing funds, however it still exposes users to the (in-)security of that individual’s upload process, which is drastically different than other Bitcoin Core release processes). Worse, we recently saw a cryptocurrency wallet be compromised due to a malicious upload of an npm package, so the attack vector is both not theoretical, and requires a high level of care when packaging.

I’m not sure what the answer is, given limited resources to actively police uploads, but, at least for the cryptocurrency space, some monitoring of the origin of wallet software is probably in order. In the case of Bitcoin Core, upstream contributors are working on maintaining a snap (https://github.com/bitcoin-core/packaging/pull/9) so hopefully we can transition to having snapcraft pull from that repo where things will get some level of peer review, but this still leaves the question of users uploading confusingly-similarly-named packages to steal funds.


#2

Have you taken a look at the security whitepapaper yet ?

https://developer.ubuntu.com/core/documentation

that should answer a bunch of the above …

the store runs automated (security) tests for every uploaded snap and will block it from being published if it does not fulfill all security requirements.

for the rest perhaps @jdstrand can answer your remaining questions …


#3

There is a review process with snaps which consists of name registration blacklists/reviews and verifying the snap in various ways. Importantly for this conversation is there is not a process for verifying a snap for correctness and while a strict mode snap is confined such that the system and other snaps are protected from it (see aforementioned whitepaper), what the user chooses to expose to the snap (eg, financial data, passwords, etc) is up to the user based on the user’s trust in the publisher.

There are a couple of things that can help the user with trust: verified publishers and ratings and reviews. It’s my understanding that both of these are under way (@pedronis and @noise please correct me/add to this as needed). If it isn’t already possible, it soon will be for say, Bitcoin Core upstream to maintain their own snap and show that snap as a verified publisher (which can be seen with snap find, eg, snap find firefox).

There is also a name dispute process as well as mechanisms to revoke malicious snaps. Admittedly, the process for reporting a malicious snap should be improved (I think @noise and @pedronis may have some more details on this point).