Hacker News Reader

The amount of cases for malicious snaps was about 1 with the cryptominer that was addressed within 3 days. Those snaps that are published go through static analysis and unless manually vetted will not have access to the rest of your system. You install it, at worst it will cryptomine that is it. Oh and you can remove it completely with all traces unlike deb equivalents.

Snaps come with a tick against verified snaps coming from first party. Such as those from Jetbrains, Mozilla, Microsoft, Amazon, Spotify etc..

If you are downloading from a software center this would all be handled for you and typo squatting will not be a problem.

In contrast with debs, the person who owns the PPA for those third party packages do have unfetted, root access to the system. The most popular PPA to this day is a closed down Java PPA run by 3rd party dev. That could easily turn malicious easily.

I don't know much about the Snap system - regarding 3rd parties and the "tick", is this using domain verification, or some other means? Do 3rd parties have to pay for this?

I read something the other day about needing to pay Canonical $15k/y for a branded Snap store, but I'm not sure if that was about private stores, this, or something else.

Another point is that when installing Snap packages from the command-line, the verification tick only appears after the install has finished, by which point it is already too late.

You can view package info prior to installing, but if we're talking about a typosquatting issue here, that doesn't really help.

I think the main mechanism of this is communication directly with developers on forum.snapcraft. In this case Mozilla with Canonical etc...

I didn't go through this process so I don't really know.

I think that is how it has worked so far for all of the 1st party snaps I have seen.

I was specifically talking about the default, trusted Ubuntu Apt repositories, not custom PPAs which are of course inherently untrusted.

> You install it, at worst it will cryptomine that is it.

If that happens then I have no choice but to assume a full system compromise and nuke my machine. It's not a risk I'm willing to take, as there's essentially no way to definitively prove that that's all the malicious Snap was doing.

> Oh and you can remove it completely with all traces unlike deb equivalents.

Snap sandboxing is rarely utilised in a meaningful way, and the permissions for a particular app are controlled by the author by default. In most cases there's nothing explicitly preventing a malicious Snap from gaining persistence even after it is removed.

In other words, Snap sandboxing is in no way comparable to a 'proper' solution like a well-configured Firejail or a VM.

>If that happens then I have no choice but to assume a full system compromise and nuke my machine. It's not a risk I'm willing to take, as there's essentially no way to definitively prove that that's all the malicious Snap was doing.

You can be rest assured that the problematic snaps were tackled and addressed within 3 days, there are no cryptominers on the store anymore. That and it was actively searched for.

Why are you downloading random crap from teh snap store to begin with?

People always take extreme perspectives over this and I find it weird. No you probably shouldn't be installing hello-world snap from Davind1923232. I wouldn't expect you to do that on Android or any other manufacturer. It probably is safe, in that it has had as much vetting as any other store owner.

Downloading firefox, vscode, intellij, vlc, nodejs, spotify and all of these other first party snaps is perfectly fine.

>Snap sandboxing is rarely utilised in a meaningful way, and the permissions for a particular app are controlled by the author by default. In most cases there's nothing explicitly preventing a malicious Snap from gaining persistence even after it is removed.

Snap permissions aren't controlled just by the author. I have disconnected plenty of plugs that don't magically reappear. Especially for sandboxing internet facing programs from my home directory.

Snaps can't magically persist that is a load of FUD. The files needed are stored on squashfs, home config and configuration in it's own isolated directory. On removal, the squashfs is removed and that is gone.

>In other words, Snap sandboxing is in no way comparable to a 'proper' solution like a well-configured Firejail or a VM.

Why do you comment on things you really don't seem to understand. This is the entire point of snap plugs/connections which are enforced permissions based model.

> Why are you downloading random crap from teh snap store to begin with?

I'm not, but the fact that there's the potential for junk to exist on the store in the first place is the problem, especially when there isn't adequate protection against typosquatting like I mentioned originally.

As long as I only use the default repositories, I can `apt install` a package I've never even heard of and it's pretty much guaranteed to not be malicious/actively dangerous. With Snap, this guarantee doesn't exist to the same level.

Sure, there is moderation and review in place, but this puts the Snap Store in the same realm as other stores and 'community maintained' package managers, almost all of which have issues with junk/dangerous packages.

> Snaps can't magically persist that is a load of FUD.

Yes, in many cases this is right, but some of the most common Snap interfaces (multiple of which can auto-connect) would provide enough leverage on a system to gain persistence or actively interact with things outside of the sandbox.

For example, the `home` interface is enough to compromise an average personal computer and probably gain persistence, as everything of value is usually within the home directory. (I do like the fact that `home` disallows access to hidden files though.)

The `x11` interface can even be auto-connected, and this potentially allows the Snap to read the graphical output of other applications.

I agree that these scenarios are quite theoretical, but as foresto says in this thread, 'sandbox' implies 'safe', and sandboxed Snaps are quite leaky compared to other sandboxes such as Firejail or a full-blown VM.

Perhaps this is just a terminology problem? I would say that Snap sandboxing is far more comparable to permission management on an Android phone.

>I'm not, but the fact that there's the potential for junk to exist on the store in the first place is the problem, especially when there isn't adequate protection against typosquatting like I mentioned originally.

If you are that concerned about typing the wrong thing then use a software center. I have never even seen one and I have been using snaps since their inception. I am using 38 snaps and I have never once installed something i didn't intend to do. I also tend not to run sudo commands without knowing what i am doing.

It's not like launchpad, or universe isn't full of junk software too. I think you can download an open source rootkit via apt as if that matters.

> For example, the `home` interface is enough to compromise an average personal computer and probably gain persistence, as everything of value is usually within the home directory. (I do like the fact that `home` disallows access to hidden files though.)

You can't gain 'persistence' just from the home interface. In fact the only way of getting 'persistence' AFAIK, is through creating a systemd snap like ufw. Again, I am fairly certain that stuff requires manual vetting before being published to teh snap store.

X11 vulnerability applies to everything, and will apply to everything until wayland is usable. Connecting it automatically means that users actually have a functioning browser. That is a sane policy because users shouldn't have to mess with configuration files to get their programs to work (unlike firejail profiles).

All you are describing are permissions which are generally needed to actually run useful programs. Yes, programs automatically connect them. I do suggest reviewing software permissions before executing it, and you can do that with snap.

>sandboxes such as Firejail

You are talking about leakyness and mention Firejail? Firejail has historically had the most severe CVE vulnerabilities partly because of how usernamespaces/network namespaces work. It was basically a setuid binary and proved a easy mechanism to get root.

Snap is built using the same tech as namespaces, but doesn't act as a setuid binary (I think because it uses mounted namespaces rather than creating a usernamespace). It uses the same seccompf, and same browser sandboxing. The bonus of snap is that it actually comes with working apparmor profiles unlike firejail.

I'm not talking about gaining persistence via a legitimately-installed system service. Instead I'm talking from a malware point of view.

If a malicious Snap has read/write access to non-hidden files within someone's home directory, you can almost certainly gain a level of persistence, e.g.:

* Edit a desktop shortcut file so that it points to your malware

* Edit a script or program so that when the user runs it, it runs your malware

* Edit a non-hidden configuration file in a malicious way

I am talking very theoretically here, and I agree that this is taking security concerns to the extreme, but these are important considerations that aren't really present with Apt (when using default repositories).

At the end of the day, despite my security concerns, I do like Snap and the technology it uses.

However, at the moment at least, I will always prefer Apt with default repositories as it provides that extra level of safety/guarantee of authenticity.

Finally, I use a script to install the Chromium Snap to remove the risk of typosquatting, which sufficiently mitigates this risk for me.

> You install it, at worst it will cryptomine that is it.

Last time I looked, snaps still had access to the X server. They were therefore perfectly capable of logging and inserting keystrokes, capturing whatever sensitive information is on screen, etc. Has this changed?

I don't think Wayland would solve this, because even if Ubuntu switches to Wayland, variants like Xubuntu (which inherit snap from the base distribution) still use Xorg.

This sort of thing is often overlooked when we talk about linux sandboxing technologies. People see the word "sandbox" and assume safety, but the fact is that most of these sandboxes are leaky in one way or another. Does it protect X11 abuse? DBus abuse? Shared memory? Microphone access? Device node access? The list is long, and the leaks are different in each of the sandboxes.

You are right, there are still issues and vulnerabilities present with using X. That is the case with every distribution mechanism ever in existence.

You would have to be a complete numpty to download and install such a thing as it wouldn't come from anything with first party support. Enough of a numpty that you shouldn't be trusted with root to begin with.

Wouldn't be surprised if this specific thing was scanned for and flagged with their static analysis tool. It seems like something that would be flagged.

> DBus abuse?

When I added the dbus slot for the firefox snap, Canonical wouldn't push to the store until it was manually reviewed. So yes, asking for new permissions/unusual permissions would probably need review.

Note that it should be possible for X server to pretend there is no other client connected to a particular program and AFAIK it already does this for remotely connected clients. Snaps could (if they're not doing this already) use this functionality to isolate themselves from the rest of the system.

>However, with Snap, everybody in the world can publish any old rubbish in the Snap Store, including packages that typosquat the names of others.

This is why I don't bother installing snaps unless the developer themselves are actually providing(or at least promoting) the snap. There's been a couple of occasions where I went to install the snap and it turned out to either be an old or broken version of the software.

I don't have too many technical quibbles with snaps, it's just the way Ubuntu has the ecosystem setup now.

Don't forget performance. SquashFS has terrible IO performance and you pay that price every time you open an application.

https://forum.snapcraft.io/t/squashfs-is-a-terrible-storage-...

There's an even bigger security hole with Snaps. If a library is compromised on apt, they'll push the update and your applications will be updated. With a Snap, every single snap developer must somehow come across the error (which could be in a sub-dependency), find the fix, then deploy again. Very few (if any) dev teams are that well connected to the development of their dependencies. In contrast, the developers of those dependencies will be very well connected.

> If a library is compromised on apt, they'll push the update and your applications will be updated. With a Snap, every single snap developer must somehow come across the error (which could be in a sub-dependency), find the fix, then deploy again.

Snaps compete with third party apt repositories, not distribution-provided packages (but see below). I've seen a general trend in complex upstreams _bundling_ their dependencies even in builds destined for apt/deb -based distribution via third party apt repositories - because handling differing dependency versions across every distribution release is too complex. In this case, your distinction is moot. In both situations it is up to the upstream developers to update their dependencies. Only that with snaps, their sandboxing security model provides some mitigation.

It is true that some packages traditionally shipped by the distribution are moving to snaps, such as Chromium. This is because these packages are moving to bundling anyway, because updating them during the lifetime of a stable distribution release has become impossible any other way, due to the same dependency pain.

This could be fixed by separating the store into an "official" repo that only includes trusted apps and an opt-in "community" repo with the rest.

It's not really an issue with snap itself.

It kinda is. Canonical explictly doesn't want to do that. The cli doesn't support any other server except canonical's.[1]

Flatpack on the other hand, does support that structure out of the box, and a few projects are already using there own repos.[2]

[1] https://forum.snapcraft.io/t/external-repositories/176 [2] https://docs.flatpak.org/en/latest/repositories.html

I can `apt install` pretty much anything I want and it's almost guaranteed to not be malicious/dangerous, as only trusted/well-established developers can get their package into the Apt repos.

Maybe not malicious, but packages in the universe repos only have 'community maintenance', meaning that they are not updated with security fixes in any systematic manner. Given that you need universe to have a somewhat useful system, most people's systems are full of known holes:

https://people.canonical.com/~ubuntu-security/cve/universe.h...

> meaning that they are not updated with security fixes in any systematic manner.

Interestingly, that exact thing was always my worry about Snap (or Flatpack) as well.

Sure, big-name software such as Spotify will keep their Snap package well in order; they've got both the incentive and manpower to do so. (Incidentally, they could also use this manpower to build distro-specific packages).

But what about all the little open-source hobby projects? They'll be packaged with whatever library version happens to be latest at the time. And then, be updated whenever the hobbyist dev finds the time and inclination.

So on my system I might have a huge zoo of different versions of the same library, with various bugs or vulnerabilities.

If they all used the same system-wide library, at least they would all be fixed at the same time (when the library maintainers publish an updated .deb).

To me, Snap and the like feel like they're essentially the same as static linking, except more opaque.

Spotify aren't doing a great job with their Snap, it's been a few versions behind Mac and Windows for a while now. They could do with more dev manpower.

Heh, interesting, didn't know that.

I was just trying to pick a random example.

This is a bug and is already fixed, debs can be installed by clicking. (Source: Alan Pope in the Ubuntu Podcast Chatter Telegram channel)

What do you mean? I'm assuming that this is a Snap Store feature?

My concern is really more about the command-line, as that's how I (and probably most technical users) install packages.

I guess my reply should be one level lower, it was an answer to "It looks like deb files only can be installed via the terminal."

I think OP is refering to snap being the default application install in the gui now rather than apt.

there's debian!