Sanitisation of snaps' requested interfaces

Am unsure if I missed it. But is there a mechanism in which only certain interfaces are allowed they are requested by snaps?

Eg, say a snap defined the i2c interface in snapcraft.yml. However, on my Ubuntu Core system it doesnt seem like the default is that all access to interfaces is granted by default. Is there a way to change it such that explicit permission need to be given?

ie. on this Ubuntu Core system, I do not wish to give access to the i2c interface, unless it is a specific snap.

As an aside, is there a way to see which interfaces that a snap will request for before installation?

do you mean auto-connect ? only a few interfaces do that, see https://snapcraft.io/docs/reference/interfaces

I meant in general that even for non auto-connected interfaces, I may not even want to allow the snap to be installed. Is there a concept of white listed interfaces in the snap world?

Installation, connection and auto-connection are different and the base declaration is where different constraints are defined. For example, by default snaps from the store:

  • are not allowed to plugs: [ snapd-control ]
  • are allowed to plugs: [ network-manager ], but the interface must be manually connected after installation
  • are allowed to plugs: [ network ] and the interface is automatically connected at install time

In addition to the base declaration, the store may include in the snap declaration constraints for installation, connection and auto-connection constraints for this particular snap that snapd should apply. For example, a snap declaration is issued for the snapweb snap to allow it to be installable with plugs: [ snapd-control ] and to auto-connect snapd-control at installation, thus overriding the base declaration. A snap declaration may allow or deny any constraints from the base declaration.

When installing unasserted snaps with --dangerous, snapd will consider the base declaration but it will make different decisions (for example, you may always install a snap that plugs: [ snapd-control ] when supplying --dangerous but the interface will not be auto-connected). --dangerous is very useful for development of snaps and interfaces, but you don’t want to install randomly downloaded snaps with --dangerous.

What constraints are included in the base declaration and why are discussed in the code review for the interface. What is included in snap declarations is handled by our store processes.

For interfaces, in general it is easiest to look at https://github.com/snapcore/snapd/wiki/Interfaces or https://snapcraft.io/docs/reference/interfaces since they will list whether or not a snap is auto-connected.

For individual snaps, today you can:

$ snap download foo # downloads foo_<version>.snap and foo_<version>.assert
$ unsquashfs ./foo_<version>.snap meta/snap.yaml # extract the snap.yaml
$ cat ./squashfs-root/meta/snap.yaml # examine the snap.yaml
$ cat ./foo_*.assert # examine any snap declaration constraints

Other links you may find helpful when understanding interfaces:

In addition to the nice and detailed technical explanation of status quo by @jdstrand, I’d just like to highlight the fact that this is a fine and sensitive line we walk through, and although we’ve been trying hard to get it right, I’m sure there is still much to learn and to improve over time, so please don’t take any particular behavior as final at this point.

The simple act of installing a snap and establishing the permissions in the system has at least 4 different parties involved:

  1. The user doing the action
  2. The publisher of the snap
  3. The device manufacturer
  4. The system supplier

Each of those has an opinion and context on the operation, and somehow we need to respect these while not crossing the line of what would be reasonable given the opinion and context of other parties regarding the same operation.

So something as simple as whether a snap may be installed or not, or whether a given interface may be auto-connected or connected at all, have a number of non-trivial angles that we need to take good care about. That’s why we have processes in place such as those described by @jdstrand above, and that’s also why we try to be public about the decision making of each particular case, so it doesn’t feel arbitrary on the consuming end, for any of those parties.