Hello, I’d like to request classic confinement for the balena-etcher-electron snap.
Etcher
balenaEtcher is a free and open-source utility used for writing image files such as .iso and .img files, as well as zipped folders onto storage media to create live SD cards and USB flash drives. Etcher was developed using the Electron framework.
The program needs access to pkexec or kdesudo to write to disk (image below with confinement: strict). Unlike rpi-mager, which uses the udisks2 plug, Etcher does not support a privileged helper running outside the sandbox, e.g. UDisks2. Etcher doesn’t use dd or any other well-known utility to write images. The developers do not intend to upstream the usage of UDisks2 for the time being, which leaves Etcher in a very delicate spot regarding confinement, hence the request.
Another would be to run a daemon within the snap, which runs as root, to listen on a socket and have a client talk to it and perform actions on behalf of the client, but this has a few problems:
your snap’s helper daemon would ideally drop privileges to the ‘snap_daemon’ user, retaining only the caps it needs to perform the operations or writing to block devices
your snap would need to provide some authorization checks on the socket (eg, group membership in the ‘sudo’ group, etc) so as to not provide a direct escalation path to root for non-admin uids/gids
your snap should provide some sort of authentication mechanism for proving that the connected user can become root (eg, sudo balena-etcher.login, your ‘login’ command checks the SUDO_UID, issues a macaroon somewhere safe that other commands in your snap verify the macaroon, etc) for admin uids/gids
your snap would need access to the block-devices interface which is superprivileged since it grants device ownship to the snap. Depending on how the above is implemented this may not be granted (though, it might be allowed manual connection with provisos that your snap implements then doesn’t change the security aspects of the above and gives the user a meaningful contextual dialog for connecting the interface. Publisher vetting would also need to be performed)
All combined, it is a fair amount of delicate security checks to end up with a security position that is less than udisks2 or your current sudo/pkexec (since the macaroon might be used thereafter). In all, I recommend working towards supporting udisks2.
You could probably come up with a scheme where the macaroon is short-lived and placed in XDG_RUNTIME_DIR of the snap which would be periodically cleaned out. You’d have to come up with an acceptable user experience for that since the user necessarily has to invoke sudo balena-etcher.login rather than your snap doing it. (Again, using udisks2 will provide a better and more secure experience).
I am not an Etcher developer, I just saw that there are a lot of requests on their github from users who would like to download Etcher from the Snap Store and tried to pack it since the developers said they were not interested in that. It sounds like using udisks2 provides the shortcut here. They have a similar problem with flatpaks. Unfortunately, I am sure if this is going to happen as the developers said that this was out of their scope for now. Etcher is available as an AppImage and a Debian package at the moment and considering that the second option also involves a serious review process it looks like the program will not be part of the store for the foreseeable future.
No, this is the paper-trail explaining why etcher can not be released as a classic snap, not a requests for packaging, like the snap-requests category provides. Feel free to open a topic over there if you feel this is valuable.
