Bogus apps in store

[mcphail]

I publish several snaps where I am not affiliated with the upstream maintainers. I publish these snaps because the upstream maintainers are not interested, or do not have the time, to publish their own.

I do not audit every line of the upstream source code. I publish these snaps with as strict a confinement as appears practical, so that even malicious upstream code is unlikely to harm the user. Occasionally, I patch the upstream code to allow the app to run under more strict confinement, and build from my patched repository. I think this is preferable to running an unconfined application.

I’m not saying your fears are unfounded. At present, a snap can be published which has access to a user’s home directory and the internet without triggering manual review, and without any indication to the user of the security risk if s/he installs the package. That’s far from perfect imho. But all of this is better than adding a PPA, or installing a random .deb which runs a postinstall script as root.

[niemeyer]

@Reynolds5

Trusting Google, Canonical or Debian developers which have proven track record is different than trusting dozens of unknown people.

… and again, you can trust whoever you choose to trust, in both models. If those are the only deb publishers you trust, then only install snaps by those as well. Most of us will also trust those plus other vendors or open source developers that we’re comfortable with.

[Ads20000]

We do need the work on a GUI in Software for connecting interfaces to go through so that auto-connections/Terminal connections aren’t required. I think this will help from a security point of view. Users will be able to deny interface connections that they don’t need and are worried about the application using and the possibility of the user denying the interface connections (something users can’t really do in Android, for example?) should encourage upstreams to accept patches that allow confinement to work properly…

[popey]

@Ads20000

We do need the work on a GUI in Software for connecting interfaces to go through so that auto-connections/Terminal connections aren’t required.

Not sure I understand. Snapd already auto-connects interfaces as asserted by the store on install. Once installed the user is in control.

[Reynolds5]

@mcphail

I publish these snaps with as strict a confinement as appears practical, so that even malicious upstream code is unlikely to harm the user.

Sandboxing is meaningless when you install malware on your system. Imagine KepassXD - rogue password manager or browser or email client or dns client… malware doesn’t have to break any sandbox - all secrets already belongs to it.

@mcphail

But all of this is better than adding a PPA, or installing a random .deb which runs a postinstall script as root.

I agree and already said that I’m comparing here snaps to official distro repositories, not PPA. Also I believe there are a lot of people who aren’t affiliated with upstream but still do high quality maintenance of snap packages but it’s hard to know that basing on snapstore info.

@niemeyer

… and again, you can trust whoever you choose to trust, in both models. If those are the only deb publishers you trust, then only install snaps by those as well. Most of us will also trust those plus other vendors or open source developers that we’re comfortable with.

All Information Security is build on trust, that’s clear. If we stick to only known developers and vendors then number of available snaps would be cut tenfold for reasons which @mcphail described.

The question is how you can trust publisher when you know only his name and email? I believe most people install snaps from store because they trust Canonical and they think Canonical wouldn’t allow hosting snaps which could harm users.

If there was warning like “This snap is published by John Doe (john.doe@example,com). This snap isn’t affiliated with Canonical Ltd. Install at your own risk.” the situation will be more clear.

There is also a quality issue when snaps are outdated and unmaintained. No one should install dnsmasqd but some users do. I know PPA have same problem but this package is in official repos of every distro and users will expect similar quality in snapstore otherwise there is no point.

You may say that Canonical provides only a platform and publishers and users are free to do everything they want but I doubt it will end happily.

[Ads20000]

If Canonical are too controlling though then they’ll get criticized for censoring / being over-controlling etc. Atm they’re taking a very radical neutral stance when it comes to managing the store. I think there were plans for some sort of verified publisher system though? Also I think the warning message you suggested could work.

@Reynolds5

There is also a quality issue when snaps are outdated and unmaintained.

Again it’s up to the users to work out what works and what doesn’t. Ubuntu reviews (at least) have been disabled for snaps and Flatpaks (in GNOME Software), maybe these need to be re-implemented on snappy’s level (rather than GNOME Software/Ubuntu’s level) to allow for independent assessment of the quality of software. Outdated and unmaintained snaps would run the risk of getting one-star ratings and reviews, which should be useful for the end-user…

@Reynolds5

You may say that Canonical provides only a platform and publishers and users are free to do everything they want but I doubt it will end happily.

Some in the community already despise certain snappy design decisions for being over-centralizing so Canonical going further here would potentially incur more anger, rather than less.

However you can see, for example, this decision for a precedent for removing outdated/unmaintained apps, as you can see, the store managers were very reluctant to do so but there is a precedent, at least, for removing an outdated snap when the snapcrafter isn’t contactable and when there’s an existing snap which is up-to-date.

[mcphail]

@Reynolds5

Sandboxing is meaningless when you install malware on your system. Imagine KepassXD - rogue password manager or browser or email client or dns client… malware doesn’t have to break any sandbox - all secrets already belongs to it.

That doesn’t make sandboxing meaningless. If a browser is sandboxed and cannot access the user’s home directory it can only leak whatever information is passed through its sandbox. Yes, that is still horrible; but it is better than the status quo.

[Ads20000]

@popey

Not sure I understand. Snapd already auto-connects interfaces as asserted by the store on install. Once installed the user is in control.

That’s amazing!!! Is that in Software 3.28 (and I’m guessing will be backported to 16.04 LTS and 14.04 LTS at some point)? Software 3.26.1-0ubuntu2.17.10.1 doesn’t have that…

[mcphail]

@Reynolds5

I agree and already said that I’m comparing here snaps to official distro repositories, not PPA. Also I believe there are a lot of people who aren’t affiliated with upstream but still do high quality maintenance of snap packages but it’s hard to know that basing on snapstore info.

The “official” way to install Google Chrome is via a .deb from Google. This nasty package adds a PPA as part of its postinstall script which has caused breakage in Ubuntu in the past, and a root cron job to replace the PPA if the user removes it. I don’t trust Google to do the right thing either. Wouldn’t it be better to have this as a snap?

[popey]

It’s in GNOME Software in 18.04. I’m sure @kenvandine or @robert.ancell can speak to the backporting plans.

[kenvandine]

Yes, that should be backported to 16.04.

[niemeyer]

@Reynolds5

Sandboxing is meaningless when you install malware on your system. Imagine KepassXD - rogue password manager or browser or email client or dns client… malware doesn’t have to break any sandbox - all secrets already belongs to it

@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.

@Reynolds5

I agree and already said that I’m comparing here snaps to official distro repositories, not PPA.

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.

@Reynolds5

The question is how you can trust publisher when you know only his name and email? I believe most people install snaps from store because they trust Canonical and they think Canonical wouldn’t allow hosting snaps which could harm users.

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.

@Reynolds5

If there was warning like “This snap is published by John Doe (john.doe@example,com). This snap isn’t affiliated with Canonical Ltd. Install at your own risk.” the situation will be more clear.

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

If Canonical are too controlling though then they’ll get criticized for censoring / being over-controlling etc. Atm they’re taking a very radical neutral stance when it comes to managing the store. I think there were plans for some sort of verified publisher system though? Also I think the warning message you suggested could work.

@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.

[jdstrand]

@niemeyer

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.

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).

[jdstrand]

@niemeyer

@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.

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/...
  

[Reynolds5]

@Ads20000

Some in the community already despise certain snappy design decisions for being over-centralizing so Canonical going further here would potentially incur more anger, rather than less.

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.

@Ads20000

However you can see, for example, this decision for a precedent for removing outdated/unmaintained apps, as you can see, the store managers were very reluctant to do so but there is a precedent, at least, for removing an outdated snap when the snapcrafter isn’t contactable and when there’s an existing snap which is up-to-date.

That’s perfect example, thx.

@mcphail

The “official” way to install Google Chrome is via a .deb from Google. This nasty package adds a PPA as part of its postinstall script which has caused breakage in Ubuntu in the past, and a root cron job to replace the PPA if the user removes it. I don’t trust Google to do the right thing either. Wouldn’t it be better to have this as a snap?

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

@niemeyer

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.

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.

@niemeyer

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.

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.

@niemeyer

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?

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

[niemeyer]

@Reynolds5

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.

[ssspacez]

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:

• https://wiki.archlinux.org/index.php/Trusted_Users
• https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines

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.

[lool]

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.

[Reynolds5]

@ssspacez

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.

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

@lool

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.

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?

[lool]

@Reynolds5

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.

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

@Reynolds5

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

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. :-/