I started writing a little storefront app using snapcraft.io API which right now allows to
- Browse snaps by category.
- Search snaps by name, author, keyword, etc.
- See snap description with screenshots and other information.
- Provide powerful navigation with results caching for a fast user experience.
The App is published here: https://snapcraft.io/qsnapstore
I wish my app to have functionalities like It can install other snap which user finds, remove them, update them, etc. for which I found this snap interface called snapd-control. Auto connection to interface will allow users to manage snaps on their system using QSnapStore. Let me know if I have to provide more information on this.
snapd-control is allowing a snap to completely take over a host machine, for this reason it is restricted to exclusively be used by brand-store owners (who typically own all the devices served from the brand store themselves).
You will likely not get approval to use it for anything uploaded to the global store …
Feeling sad to learn about this
Even without the user’s consent? I mean no root password or anything is required?
For some bits you might need extra privlege escalation, but essentially (like any other package manager) snapd runs as root and has the ability to install any snap at any confinement level you can imagine …
so even if you can not abuse the interface directly, you can enforce the installation of an insecure classic snap that runs system services that contain a key logger, encrypt your files (to ask you for money for the unencryption key) etc … this is why this interface is not allowed to the general public
Thanks for providing details about snapd-control interface. It would be nice to have this information documented in the official documentation at here.
@degville what do you think ?
Absolutely, yes. I’ll add the brand-store caveat now. Thanks for pinging me.
So from a security PoV,
snapd-control is super privileged but that does not mean there is not use-cases for it being granted for use and being auto-connected - we do this at the moment for other graphical snap front-ends like
But since this is so privileged, to be granted it would require something akin to the publisher vetting that we perform for classic snap requests as well as perhaps some other guarantees so that any possible misuse of the interface could be controlled - such as publishing the snap via Snapcrafters.
The other thing to consider is that the other snaps that I mention above are well known and well maintained upstream - to be considered for use of / auto-connect of
snapd-control I would expect the same for
qsnapstore - @keshavnrj can you elaborate more on QSnapStore? Is this being used by any distros already, what is the upstream projects intention for the snap - will this be a long-lived project or is it more just a toy?
Finally, it would also be good to get input from the @advocacy team as well - @popey / @Igor do you have any guidance for community use of
Not aware of any existing guidance in place, but this is rather delicate. Maybe there is a place for a custom interface that could satisfy only a subset of requirements, like installation of new software but no ability to touch “privileged” snaps?
IIRC, the snapd team was discussing carving up the API but that is still in the design phase AFAIK. Of course, installation gives the ability to install classic snaps which can have root running daemons and snaps that plugs super-privileged interfaces. The current API allows the ability to auto-connect, set config, etc. Even if we carved up the API and only allowed installation/refresh with no other functionality, we would still want to perform vetting to ensure that policykit was in use with no intent to remove, installing snaps in the background, etc, etc.
In addition to this, what is the privilege separation model used by qsnapstore and what mechanisms are employed to prevent non-root users from escalating privileges to install new software (eg, policykit)?
QSnapStore is just a hobby project, which aims to serve simple and fast user experience to users. It is a very simple app written in Qt 5 (https://github.com/keshavbhatt/qsnapstore). Yes the app will sustain longer and will be actively maintained by me, if it will be provided proper functionalities like Install and update packages.
I was not aware of the permission model of snapd-control interface before i started this project. For now its just a simple snapstore browser with around 1k active installed as per metrics.
I have no intentions to harm any user, matter of fact i came to know about the super privilege mechanism of snapd-control from recent comment by @ogra 's feedback. I thought it would be like me calling snap install someapp and user would be asked for password like in the snapstore app.
@keshavnrj thanks for the response, so given this is a hobby project I am less keen to grant this use.
snapd-control allows complete device ownership, and so this is something which should only be granted for very trusted applications. Also whilst you may have no intention of harming users etc, if there was a vulnerability in
QSnapStore that allowed a remote attacker to control it, then they would gain instant device control.
Can you elborate as @jdstrand asked above about the privilege model of
QSnapStore - does it include say a unprivileged front-end, and a privileged back-end with policykit authentication or similar to ask for authentication when installing snaps? If not, can you explain how it currently works from a privilege model?
QSnapStore is and will be strictly confined,i don’t know how someone can take control without given permission.
There is no such mechanism built in yet, though there will be one. Qsnapstore right now just let users browse, search applications from snapstore API. Snap management was a feature that was in roadmap.
Since there was already a Snapstore app, which keep breaking everytime (still broken and have lots of bugs) I decided to make a simple working counterpart. I said hobby cause there is no other option to call it according to me. No one asked for an unofficial store and hence it started as my personal project. Someone suggested that it would be nice to ask for the permission first before furthering the development of app. So, in case if the permission was granted i would be actively developing this.
Thanks for your interest in this
@keshavnrj thanks for the response - you state above that
QSnapStore currently allows searchign and seeing description etc - so does it even need
snapd-control at this stage, if it is not actually wanting to install snaps etc? Can you please clarify?
@keshavnrj - ping, can you please provide the requested information?
I was planning Qsnapstore to have the ability to install and update snaps and was on the way to do that, but someone in the Ubuntu podcast chatters group told me to confirm here first for the snapd connect permission before putting further efforts in developing the Qsnapstore. So i decided to confirm if Qsnapstore will be getting permission or not.
Since i came to know that the permission cannot be granted in the discussion above, I stopped working on the app and hence didn’t implemented the install/update feature.
Thanks for your understanding. As explained above, since
snapd-control allows complete device ownership there is a process that must be followed to grant such declaration. If in the near future you decide to work on this app/features again, please re-open this request, and make sure you include the privilege model, and the detailed project information as requested. We will be happy to review it again.
I am removing this request from our queue in the meantime.