Currently desktop users are able to install snaps from the store using GNOME Software.
There’s a couple of cases we don’t yet handle, but we (probably) should:
- Snaps using classic confinement (these currently fail to install because we don’t pass the classic flag to snapd )
- Sideloaded snaps . These may require devmode or be unsigned.
- We do want to support both these cases in a graphical environment, right?
- What safeguards do we want to use to ensure a user doesn’t install a malicious snap using these methods?
With safeguards, we can:
- Indicate on the app description page that this is unconfined app.
- Show a dialog box to get the user to confirm installation (danger being that people often ignore such boxes and just click “yes”)
I’ve started a discussion with upstream about how such things could fit into the gnome-software design .
For comparison, this is the command line experience in installing a classic snap:
$ sudo snap install atom
error: This revision of snap "atom" was published using classic confinement and thus may perform
arbitrary system changes outside of the security sandbox that snaps are usually confined to,
which may put your system at risk.
If you understand and want to proceed repeat the command including --classic.
$ sudo snap install --classic atom
I think this quite secure because it requires sudo (implying a lot of responsibility on the user) and the command has to be re-typed to confirm the behaviour. I’m a little worried that these responsibilities are less clear in a graphical environment.
From a security standpoint, I’d be happy if sideloaded snaps weren’t made to be easily installed through GNOME Software and they remain only installable through the snap command line client.
I think it does make sense to support the installation of classic snaps in GNOME Software. I don’t have much to add outside of what I’ve already mentioned in the bug. To summarize, I’d like to see a clear warning displayed to the user. A prompt is not necessary, IMO, as long as the warning is in close proximity to the Install button.
But Debs can be sideloaded and they’re less secure because they’re not confined?
I guess there’s no reason not to upload a snap to the snappy store though and it’s really not very difficult, whereas it’s more difficult to upload a Deb to a PPA (and expect users to add the PPA) or the Ubuntu repositories and keep it up-to-date…
However, if we want to enable user-friendly offline installs (and offline updates), then we need the ability to sideload snaps using GNOME Software.
If there was a way to install
.snap files and
.assert files graphically that would be useful, then you could install a signed snap, by installing the
.assert file, then the
Are there any limits on the contents of classic snaps? Being able to search in GNOME Software and with a single click install it seems a very easy way to install a malicious package. In comparison, you have to opt-in to a PPA before this is possible in the .deb world.
No, there are no limits for what is in the snap or what it can do, but all snaps using “confinement: classic” require a snap declaration to allow that publisher to use classic for that particular snap. There are a series of questions that are asked by the store reviewers (usually asked by the advocacy team, eg @evan, @JamieBennett, etc) to determine if the request is reasonable and from a reputable publisher/upstream.
I agree with @tyhicks that users installing classic snaps should be able to see easily that the snap is a classic snap with information on what that means. This is important so that they know that it isn’t confined at all and also because they may have different criteria for what to install on their systems than the store reviewers for what is included in the store.
This is the branch that @jamesh worked on:
Note that the warning is only visible if the window is tall enough, otherwise you would have to scroll down to see it.
I’m concerned that this is not visible enough, but as pointed out classically confined snaps are considered reviewed by the store. Can design / security confirm if this is suitable?
I find the wording of the warning way to tame since this snap “will have access to all your files”, not just documents, but also dot-files with passwords, browser cookies and whatnot …
The message should reflect that risk …
Note that it is typical for packages installed from the software center to have access to all the users’ files. What is different here is that this is a binary package coming from a 3rd party that is only accepted based on trust between the party and the reviewers from the snap store. I think this is what needs to be emphasized.
I thought this is about classic mode snaps ?
Yes, but compare the wording on the Atom page and on the page of any other non-snap app in the software center. All those other apps can access your documents and cookies.
Has there been any more progress on this issue?
This is coming up in up in work I’m currently doing on the store’s snap pages
We do support installing classic snaps but we don’t support sideloaded snaps. There doesn’t seem to be a strong demand for sideloading and the security opinion seems to be they aren’t a good idea.
I just tried installing Slack (which uses classic confinement) using Ubuntu 17.04, with this error message:
snapd returned status code 400: Bad request and so used the terminal. Is there a fix in the works?
What defines sideloading a snap? Is it installing a snap that has not be signed by the store?
Sideloading is an archaic term that we’ve been trying to avoid because it doesn’t covey the meaning of the actual case at hand.
There are two possible installations that can happen in the local system:
Installing a local snap that has proper signatures. That operation is completely fine as far as snapd is concerned, with almost no differences compared with an installation directly from the store.
Installing a local snap that is unsigned. That’s considered a dangerous operation, because the content and the origin of that snap are completely unknown. It also has no revision information, so snapd creates a local sequence for the snap (x1, x2, …).
By sideloading I mean installing a snap from a .snap file. The ‘side’ refers to coming from a side-channel rather than the standard snap channel (i.e. from the store). We currently support neither of the cases that @niemeyer listed on GNOME Software, instead requiring the user to use the command line to do this.
Ubuntu 17.04 is end-of-iife - did you mean 17.10? Which version of GNOME Software is this?
Right, that’s the historical meaning, which we’re avoiding because it’s a bit confusing. A local snap file may be a fully supported installation operation, completely blessed with signatures and everything else, and it may also be a dangerous operation, as explained above. So the fact the snap is local is not meaningful by itself.
We suggest using the term “unsigned” for the dangerous operation, and simply a “local install” for the other case, which isn’t really too special as far as snapd is concerned.
Thanks for the sideloading 101
If a user sideloads a signed snap (local install), will that be detectable using gnome software? As in will be able to launch/remove it? I’m assuming it uses the conventional revision system as it has passed through the store at some point.
It was with 17.04, I don’t know what version of gnome software was running at that time. I updated to 17.10 last night and I’m having issues trying to boot the computer . I’ll troubleshoot today and get back to you.
Whether you download the snap and its assertions or whether snapd downloads it, snapd won’t know the difference once the snap is installed.
That’s why we don’t want to talk about “sideloading”… it drives the mind off into the wrong direction. There’s nothing so special in that operation.
You may want to update the API docs then.