Questions about security of snaps

Hi, I’m not a developer, I’m just a normal user of snaps, and I have some questions about security because there are some things that are not clear to me from the general documentation (unless I missed something of course).

Snaps are supposed to be “secure” because they live in a container, and to be able to use some dangerous functions (like reading and writing from the file system) they need to be manually reviewed and approved. What I don’t understand is:

  • If a developer is allowed to read or write a file in ~/appfile, are any subsequent changes to this permission going to be detected and blocked (requiring manual approval), or is the developer able to expand the reach of their permissions once an interface has been approved? In other words, I’m wondering if the approval process is continuous (and permissions must not change even one bit, otherwise a new approval is required), or if the approval process only happens at specific times (and after that a package is “trusted” and its permissions might change, even slightly, without other approvals). I don’t know if it’s clear. But a practical example would be a dev that has permission to write to ~/appfile, and later on in an update they decide they also want to write to ~/otherappfile. Will they be able to, without triggering another manual approval?
  • If a user changes the permissions for an application (using the snap command), when the application is updated are those permissions always going to be retained? Or can an application force its permissions after an update? In practice I’m wondering, if an app has permissions to connect to the audio interface, and I decide I don’t want it to connect to that interface (disconnect it), is it always going to remain disconnected then? Or after some update, it could “magically” become connected again?

I hope my questions are clear enough. I’m just trying to understand if the method for managing permissions / interfaces / connections / etc. is solid and cannot be bypassed in unexpected ways.

anything in ~/ does not need special approval if the snap uses the home interface, this allows generally access to all files and dirs in your home with the exception of “hidden” files and dirs (i.e. files or directories that start their filename with a dot) only these need special interfaces and you would create a self explaining plug definition for this particular dir like dot-appfile and the user would always have to manually connect this by default. this particular dot-appfile interface you create would need explicit approval once for your first upload of the snap to the store. all subsequent uploads will not need any extra action.

yes, the permissions on a system stay as they are until the user/admin changes them.

Thanks, but does that mean that the following process is possible then?

  • The developer creates a snap and defines a plug to be able to read and write ~/.appfile.
  • The developer asks for autoconnection permissions.
  • Snap store maintainers see it just wants to read and write to that dot-file, and they say it’s ok
  • Later on the developer releases an update where the plug is actually going to write to ~/.bashrc
  • Since it’s the same interface (personal-files, read and write dot-files), nobody notices and no approval is needed
  • The developer can now compromise the whole system.

No. Because the permission system would allow the application access to ~/.appfile, not ~/.bashrc.

no, the personal-files interface is bound to the filename and also needs to have the filename in the plug name (dot-appfile) so the user knows when connecting which file/dir she allows access to. there is no way to access any other dot files here unless a new interface plug is added, approved and manually connected by the user.

Thanks. I was afraid the personal-files interface was too permissive, and/or the review and autoconnect process was only performed the first time a developer requested the interface. So it looks like everything is safe enough.

1 Like