Perhaps a post on this is already planned but so that one does come on the forum eventually I’m posting this…
What action will be taken to try and minimize/eliminate the amount of malware that comes onto the snap store in the future? Automated checking of apps uploaded? I thought this already happened? Also could apps that are removed be replaced by dummy packages (that, if possible, run something to ensure there’s no trace of the malware left on the user’s computer, as far as this is reasonable) to ensure that they’re removed off the computers that the apps are installed to?
As end user, I expect these things (maybe they are addressed from some other discussions, if so sorry):
No internet access for snaps, and they have to ask permissions on first start - something like the modern Android security model. While it wouldn’t stop a miner, at least attackers cannot collect what they mined. Of course this would work for games (I don’t want to give Internet access to games), but not for other things.
Check on license: why a snap that builds a public Github Repo shouldn’t have the same license?
Verified authors: there is an aws-cli package, the author is listed as awson the store, but the repo’s authors say its not theirs. While I trust @popey because I know him, so I believe it’s owned by AWS, as a random user I wouldn’t trust just a random comment on a Github repo and give my company’s AWS credentials to a snap with a doubtful ownership
Easy to find link to the build log, if available (e.g LP)
We initially removed the snaps from the store, and subsequently re-published them without the crypto miner, so anyone with the snaps installed will get automatically get refreshed to a clean versions.
Looks like a verification system is being created:
a simple but fairly effective feature that we are working on is the ability to flag specific publishers as verified. The details of that will be announced soon, but the basic idea is that it’ll be easier for users to identify that the person or organization publishing the snap are who they claim to be.
That post covers two changes relevant to this case:
Announcing that software being “misleading” is a reason to remove it from the store.
Upcoming introduction of verified publishers.
Here are some other measures that could deter similar cases:
Making the rule against misleading software more specific and easier for developers to find. That is, including it in the developer terms, which already cover things like libel, defamation, and inciting violence.
Having a rule against mining as a non-core feature even if this is disclosed to users. Apple removed a calendar app that mined cryptocurrency, even though that was disclosed as a GUI setting, for violating their guideline that “Apps should not rapidly drain battery, generate excessive heat, or put unnecessary strain on device resources”.
Reminding publishers of the developer terms on at least the first snapcraft push, or GUI equivalent, for each new snap.
A “Report as inappropriate” function, so that someone doesn’t need a GitHub account (or even an SSO account) to request takedowns. (As should go without saying, this is separate from user reviews. For example, if a snap uses someone’s artwork without permission, recommended recourse shouldn’t be leaving a one-star review.)
What about explicit minig apps ? We should have a exception here (using a snapped miner in an UbuntuCore based mining park seems like a really good use-case) mining apps published under their upstream project name (or by their upstream developer(s)) should be excluded from this rule.
-1 - this would make it unduly difficult to establish a conversation with the reporter to find out more; and therefore impede our ability to establish all the facts.
Let’s not succumb to the perpetrator’s choice of language. This wasn’t legitimate monetisation of an app; it was malicious installation of a trojan for the purposes of theft. I agree we need to allow paid apps to thrive, but this should not be the impetus.
For the specific case of “This app does something bad to my machine”, it might be reasonable to require sign-in. For copyright/trademark/identity infringement, it would not. (If you’re already angry that your rights are infringed by something on a service, and then you’re told that reporting the infringement requires signing up for an account that is of no earthly use to you, it’s quite likely that you’ll become enraged with the service as a whole and tell people not to use it.)
Fortunately, that would require showing only two extra fields in the report form if you aren’t signed in, name and e-mail address. I don’t think that counts as “unduly difficult”.
I notice that the blog post is not listed on the https://blog.ubuntu.com/ homepage, despite being on the blog, I guess it’s not something Ubuntu/snappy is proud of? xD Or maybe not all posts are listed there anyway, I don’t know.
I think it was said that manual reviews for every snap would take too long, but distribution maintainers manage to do it for a fairly wide range of applications and there’s been no incidents that I’m aware of where a distribution has had malware in their repositories? Maybe this could be replicated with the snap store after all? Then again, maybe the snap store is likely to have more applications and updates than even Arch, I guess there’s no split between official and community repositories so it is a big number of snaps that would have to be reviewed if the manual approach were taken…
