Hello, I’d like to request classic confinement for the
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.
Source repository https://github.com/balena-io/etcher
Snap repository https://github.com/gantonayde/balena-etcher-electron and snapcraft.yaml
Classic confinement request
The program needs access to
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.
Direct access to sudo/pkexec is currently an unsupported use case for classic. Updating the application to use an external helper like udisks2 is the best way to go.
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.