5

Today Ubuntu (and some other distros) offer a new way to install software, which is snaps. It's software packaged with all its dependencies, run with some kind of containerization, and auto-updated. This might make it sound like it's definitely a safer option, but when you think about it it actually depends on several factors, and probably the most important are:

  • Containerization sounds like a good thing to have, but what kind of containerization is it exactly? Does it really help? Plus, you aren't asked what you want to allow or disallow when you install a package, so I suppose the application itself decides whatever it want to access on the system. I guess it might prevent the exploitation of some vulnerabilities only if the application is correctly restricted by the developer (or whoever packages it), but will it help against a compromised or malicious application?
  • Maintenance seems to be much better for snaps, which appear to be all up-to-date (latest branch and patches) and updated pretty quickly when a new version is available. Software in official repos is always old versions (although hopefully patched but in a way that is not evident from the version numbers), so it's not clear how quickly and what, if ever, will be patched in the repos. However the problem for both snaps and repos is: who the hell is maintaining the software, and is the supply chain equally secure (or insecure) in both cases? I tried checking the maintainer for several popular packages in the official repos, and it's always "Ubuntu Developers" (whatever that means). If you do the same with snap (snap find <whatever>), you will see lots of different "publishers" (whatever that means). For example gimp, ffmpeg, android-studio and lots of others are published by "snapcrafters"; vlc is published by "videolan" with a green checkmark (verified publisher, whatever "verified" means, since at the moment there isn't even a way to become verified, it's just "Canonical's friends" I guess); keepassxc is published by "keepassxreboot"; john-the-ripper is published by "claudioandre-br", who on GitHub seems to be a developer who forked and patched the official John The Ripper. So it's all very confusing.

So the question is: are snaps a more secure alternative to the official repos? If a user wanted to install, say, Keepassxc would it be safer to install it from the official repos or with snap? Or what would a user need to check before making a choice?

Note that for example the latest version of Keepassxc is 2.6.6 (from the official website), and snap provides version 2.6.6 (so it's easy to see this is fully patched) while Ubuntu's official repos have 2.4.3+dfsg.1-1build1 (I suppose and hope it's an old version that has been fully patched for security issues, but it's not clear from the name). You would definitely be tempted to install it from snap, until you remember that snap is a relatively new thing and I have no idea how much I can trust the whole process. And that's what made me ask this question.

2

2 Answers 2

2

Security here is based on whoever you trust more*: Canonical or the application developer. At the very least, you know that Canonical is a legitimate company and not one that purposely makes malware (in the traditional sense, at least). The application developer may also be some huge company, or it could be a developer you've never heard of which could very well be a legitimate developer, but you're not necessarily sure about that if you've never heard of them before. You also aren't confident about their skills in writing secure software.

Snap is one way you can transfer some trust from the application owner to Canonical. By using snap, snap "sandboxes" a process in several ways: for example, it's given its own directory under /tmp to do work in instead of operating directly in your home directory, and what it can do is limited to "interfaces" that you grant it permission to use [1]. This is similar to how mobile devices, such as iOS and Android handle sandboxing: when an app wants to do something, say "write to your home directory", they have to have permission granted to them (on install of the app though, I don't believe there's an explicit prompt to do so). It simply happens that the possible permissions are broader than what most mobile OSs ordinarily allow to be granted: for example, writing files except to containerised directories is prohibited on iOS, but a permission is available for snap apps to use.

If, for example, a developer writes a program that can take a filename and delete it, supposedly only files that are controlled by the app, and his app executes something close to rm -rf /home/username/foobar-app/{NameOfFile} and has poor input sanitation, it's conceivable that a bad actor could put the name of the file as ../../../, deleting the entire system. snap would prevent an app that doesn't have permission to modify files outside of its own directory, thus preventing that.

Snap, however, has some closed-source components, so it does rely on you somewhat trusting Canonical (though I believe the client side components, which are the ones that are actually doing security stuff, are open source) on distributing the correct software to you, but I seriously doubt Canonical would risk their reputation by injecting malware into your software.

*You could also trust an open source app itself because you read through the source, but in terms of security it's similar to trusting the developer that wrote (and thus read) the source.

0

Sometimes, sometimes not.

Snaps as they're currently packaged are a hardly a boon for security. For example, if you

  • Install Debian with Gnome desktop and run Chromium as packaged by the repo, you'll find that you have a working copy of the gnome keyring and libsecret integration.
  • Install Ubuntu with Chromium packaged by Ubuntu using snap, you'll find there is no libsecret integration and your cookies are stored with a hard coded private key rather than a randomly generated one placed in the keyring.

This means effectively your system is more protected from a compromised version of Chromium reaching into your operating system. But your browser is less protected against a compromised system that wants to exfiltrate your data in Chromium: anything with read access to the database in ~/snap/chromium/common/chromium can jack your session on anything you're signed in on.

I'll stick with Debian.

I went ahead and filed it upstream as a misconfiguration https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/2038875

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .