Bogus apps in store

Yes, that should be backported to 16.04.

2 Likes

@Reynolds5 We are mostly in agreement. That’s why you need to trust the publisher, even if there is sandboxing. But sandboxing helps, even then. I do not trust any online password managers, for example, and local password managers can be 100% strictly confined. No access to anything. If there’s malware inside that sandbox, it cannot do much.

We understand, but this project aims at solving a larger problem, which includes reality based on data analysis. PPAs and third-party packages and repositories are extremely popular. So for this conversation to make sense at all we need to account for those.

Yes, that’s suboptimal, and we’ll work to improve this situation by introducing some level of publisher verification. But again this isn’t much different than other online trust building: how do you trust code in GitHub? How do you trust code from a third-party PPA? There are many answers and I don’t intend to go over these details, but the underlying point is that this isn’t much worse.

We show something very similar to that when people install unconfined snaps, and we always put the publisher name next to the snap name when listing or providing information about a snap.

@Ads20000 Yes, we’ll implement verification of publishers, so we can at least be more certain that there’s a real person or entity that corresponds to the name.

3 Likes

To clarify “100% sandboxing”: if the snap doesn’t plugs network or network-bind, then the snap can’t send off the passwords somewhere. This sounds very reasonable for a password manager (even if it does plug x11 or unity7 (which due to X limitations, allow keyboard sniffing), since it can’t ship off anything it sniffs).

This will be hugely helpful. How that is surfaced to the user will of course need design. I’d also like to see a link to a source build like we have in LP surfaced somewhere. Obviously this isn’t exactly how it would be surfaced, but if we had information like this, it would give people meaningful information on whether or not to trust the snap:

  • example proprietary:

    Name: foo
    License: Proprietary
    Publisher: Foo Incorporated (Verified)
    Build info: Unavailable
    
  • example open source:

    Name: bar
    License: GPLv3
    Publisher: First Last name (Unverified)
    Build info: https://launchpad.net/...
    
2 Likes

Yeah, this is the choice - “walled garden” or “freedom platform”. Canonical is in pretty special position being constantly accused of creating the former even if they wanted to create the latter. I hope this discussion will balance those arguments.

That’s perfect example, thx.

If published by Google/Canonical - absolutely. If published by John Doe - I’m not sure.

The same person who publish snap decide about confinement details. Even local password managers may have sync feature or ability to talk to browsers so giving them network plug isn’t unimaginable. Malicious browsers, email or dns apps are indefensible.

I’m not trying to do general security overview of snaps packages. There are a lot of great security features and people are generally doing great job, otherwise I wouldn’t bother. I’m concentrating on weak spots because critical discussion is a way for helping this project. I hope this doesn’t look like a two sided battle: me vs everyone else due to my criticism.

Paradoxically snap install process which is very user friendly give me less clues about what I’m exactly installing than installing from github. The thing I know for sure is it will be sandboxed but as already said for some critical apps this is marginal improvement.

To summarize, things which in my opinion will improve situation:

  • Publisher verification (which is already planned)
  • User reviews/comments in snapstore
  • Unpublishing misleading/bogus/malicious snaps from store after tried contact with publisher (this can be rule based or discretionary). Good examples are mentioned telegram-latest and dnsmasqd

Thanks for the exchange, and for the suggestions. We are working on all of those ideas already.

4 Likes

I will quote some ideas that I’ve posted recently:

For terminal: put the word “official” somewhere when the snap is from the official developer so people can trust it and install it.
For stores: a green checkmark ✓ with the word official near the name of the developer would be helpful.

It could be “official” or “trusted” or similar concept, the idea is to ensure the user that he is not being misled and installing a random snap from a random person.


Also, about comments/reviews reminds of Arch’s AUR, they have a way to mitigate the problem too, they use a Popularity rank, it’s usually a bad idea to install anything from the AUR that has 0.00 popularity or near 0.

Arch’s Trusted Users:

There are other ways to improve this, for example the total downloads of a snap could be used, or the same data by downloads/month or another time period. The idea behind is “if it’s popular it’s probably safe”, this is not always true but it helps, it adds another layer of security.

Hi,

I’m the publisher of the snap(s) which were originally quoted in this post. Full disclosure: I work for Canonical and am a recovering Debian and Ubuntu package maintainer.

The topic goes beyond the specifics of these snaps, but I wanted to respond to specific points.

On licensing, I didn’t set any licensing and the store picked up proprietary, I guess as a safe default. This was wrong on my side and I guess to improve this we could trust the store to set a better default in the future and improve our tooling to scan for licenses automatically and warn when it can’t be done.

Snap names are a central concern here. An upstream-ish name will get some unwarranted implicit trust, and I engaged in namespace pollution by using too broad names like dnsmasqd since I didn’t actually intend to maintain a dnsmasq snap in any kind of upstream capacity. That said, others have made the point that it might make sense for a non-upstream person to maintain a snap until upstream picks it up, and it’s hard for end-users to distinguish between these cases.

Funnily enough, in an early design of “snappy”, snap names were namespaced, so you have installed lool.dnsmasq and I would have had to ask explicitly to get an official dnsmasq alias.
(see e.g. https://www.unixmen.com/getting-started-with-snappy-ubuntu-core/ for samples)

While it’s easy to find/check the publisher of snaps before and after installing, I started suffixing my snap names with -lool in the past months to mimick this behavior.

But still, snaps can be leveraged or deliver official packages with official names from official upstreams, or they can be more like GitHub or Google Play Store.

I guess similarly to SSL certificates or Twitter accounts, there could be more work invested into verifying publishers on the backend side and there could be more work to expose this on the client side (such as deciding which publishers to trust/not trust).

This discussion was centered around potentially malicious use, but there’s a simpler path to bad snaps (outside of quality, store reviews/comments and general end-user experience) that I’d like to highlight: security updates. Dnsmasq snap needs to be updated whenever there’s a new upstream security update.

I’ve made some of my (non-suffixed) snaps private for now. The dnsmasqd snap was created because I was asked for a TFTP tool and also as a demo of a cross-compilation example, but also because I thought it would be useful to have it around for me and others in quick debug/DHCP/TFTP situations. I’ll stick to suffixing my non-official snap names until we have better mechanisms in place to document verified and trusted publishers.

2 Likes

Being a long time Arch user I’ve never ever looked at popularity rank but for inexperienced users it can be a guidance. So are users comments to each package. IMO the main advantage of AUR is ability to easily inspect PKGBUILD (something like snapcraft.yaml) but again some users may not knew what to look for.

@lool Thank you for answering in this topic. I’m sorry for giving you such bad press but you were an easy target :smile:

Submitting snaps with “upstream” name which didn’t exist before is acceptable for me. There could be an “official badge” for snap maintained directly by upstream which will make situation completely clear. What is questionable to me is submitting apps which are already in repos by someone other than upstream and try to mimic the original.

One question: why did you use your own repo as source instead of upstream?

1 Like

(I quite like the “this snap is maintained by its official upstream” badge idea)

My memory doesn’t serve me well because I thought it was to include a one line patch to dnsmasq to make it cross-build with the default env vars that snapcraft had set, but my repo has zero patch, and I do not seem to have added any snapcraft.yaml trick to make cross-building particularly work. I do remember the upstream repo was slow to pull from back then, but it could have been transient. Or maybe build.snapcraft.io / Launchpad didn’t allow pulling from non-whitelisted git servers back then?
One thing which bugged me was that I wanted to do something like “build against the latest upstream release” instead of hardcoding a release in the source tag and snap metadata, so that would have been either including the snapcraft.yaml in the tree itself (I don’t have upstream commit access, but could have contributed it), or having build.snapcraft.io smart enough to trigger builds when the source-git upstream branch changed (which might not be doable against random git servers) – however, I didn’t want to build against git master as that would be too volatile, I had no idea about stability of tip of the tree. Also, I think there was no way back then to map the upstream version tag into the snap metadata.

But bottom-line: I don’t remember. :-/

As expected snap are used for delivering malware in the wild:

https://github.com/canonical-websites/snapcraft.io/issues/651

No need for theorizing anymore.

Just create a prompt that asks the user if he wants to install:

  • This developer is trusted, do you want to continue the installation?

  • Warning: This developer is not trusted yet, more testing is required, do you want to continue the installation?

2 categories, trusted/not trusted yet.

And create a system to promote manually or automatically developers from not trusted to trusted. The criteria is up to snapcraft. Maybe a quarantine period until the developer gets trusted, I don’t know, this is a complex subject.

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.

I’m still thinking that package verification is more important than developer verification. Using non-upstream sources and custom files should be a big red flag and a no-go by default. Spotting it will take 5 min in manual review. That’s why config used for building snaps should be linked in store.

I think protecting users should be more important than ease of submitting new packages by developers. When users start to being afraid of installing snaps then the whole project would be undermined.