Strict confinement requirements

snapcraft
#1

Good day!

I have a very simple application ws2connect that I wanted to share with people as a snap package for their convenience.

I supposed that snap packages aimed to provide secured, always fresh and developer-maintained applications that could be easiely installed by a target customer. I was one of believer of the idea and even released my previous applications: fluent-amqp, monexec and redirect-to. That were a quite simple utilities released fully free of charge for system administrators and advanced users. With several attempts more or less I published applications.

Today, after a year of interruption, as I tried to release ws2connect (as mentioned above) and got unpredictable stop factor: requires a human check because application needs to access to home directory.

To be specific - I am not against human checks, but I am super confused about non-transparent documentation of plugs: my damn simple application just can read file (for certificates), serve http/https server and connect to any UNIX/TCP/UDP/TLS hosts. What should I use in plugs? I don’t what to restrict users to use only home folder for their configurations files: maybe they what to use system folder or even external drives… But it three different kind of plugs! Same situations for network: application CAN be bound to any port, for HTTP or HTTPS protocol, it CAN connect to any hosts and in case of TLS connection it HAVE to access to system certificates that usually (but not always) located in /etc/certs…

Could you please recommend what kind of plugs I should specify?

I am sorry for a little bit emotional question, but that situations seems like will not help grow popularity of snap packages. At all. Restrictions feels to be too granular and complicated to use. Maybe it’s ‘OK’ to big stable packages but for utilities and small community driven packages it’s really inconvenient. Just imagine: I would like to deliver latest updates to my customers using edge channel for latest snapshots, however, in case of manual review it will be a bottleneck and super overload for reviewer. There are three future scenarios for reviewers for the situation: (a) decline packages (result: snap will not be used by authors), (b) inspect packages on high-level (result: no security impact of such checks - so the step is useless) or © extreme delay for packages delivery (result: reduce interest from target customers - snap will not be used by authors).

Could you please describe plans how Snapcraft community plans to solve a problem described above?

#2

Hello! Let me try to answer this question but also sorry for a late response - most of us have been on holiday for two weeks.

Human review can be required for several reasons[0]. In this case, it sounds like your snap is requesting auto-connection of an interface (home) that is not already being auto-connected [1]. As mentioned in [1], the developer wishing an auto-connection to be turned “on” in their snap will require them to request such access.

Having isolated applications is one of the goals of snaps, so it is sometimes traded for the inconvenience of needing to request some accesses. This barrier causes developers to question whether they need certain accesses, leading to applications explicitly requesting minimal accesses. This somewhat tight control is to try and minimize granting unneeded access to applications, in order to maximize the isolation of the snap.

In the case of accessing the network plug, that should already be available to you since it’s already auto-connected.

It also might help to know that you can install review-tools to get more detailed information about what could be causing your snap to trigger a human review.

$ sudo snap install review-tools
$ snap-review name.snap

name.snap = whatever the name is of your built .snap file.

Hope that helps!

[0] Extra permssions: https://snapcraft.io/docs/permission-requests
[1] See list of interface names and their auto-connect status: https://snapcraft.io/docs/supported-interfaces

1 Like
#3

I looked in the store and see that the manual review was triggered by use of personal-files. Looking at the snap.yaml, I see it is using:

apps:
  ws2connect:
    plugs:
    - personal-files

This isn’t proper use of the personal-files interface. Please see The personal-files interface for more details.