My snap "lbe-device-management" was rejected on the store

store
1

Hello,

My snap “lbe-device-management” was rejected on the store.
The message was:
“The snapd-control interface is reserved for snaps that require device ownership and the ability to control all aspects of snaps on the system and is not usually needed for typical snaps. If the access is required, consider using a brand store or create a forum topic at https://forum.snapcraft.io/ using the ‘store’ category if this can be discussed in public or the ‘sensitive’ category if the discussion should remain private. Please feel free to copy and paste this message in the topic. Thanks!”

The purpose of this snap is exactly what is described before: “the ability to control all aspects of snaps on the system”.

Could you please unlock it?

Best regards,
Corentin Damman

1 Like
2

Hello,

Thanks for presenting your request here!

Because snapd-control confers a lot of power over the device, granting use of it is not a simple matter of approving use of the interface. Security reviewers must carefully consider the use case and will probably request details about the snap.

Quoting from another topic:

we’ve thus far severely restricted what snaps could use snapd-control in the public store since the interface grants device ownership to the snap, and granting the snap declaration strongly implies that this snap is safe for everyone to use.

Given that, and that you are not using a brand store (which would limit the snap to being installable on a specific set of devices over which you presumably would indeed have control and ownership), it would be great if you could provide a more detailed explanation of what the snap’s purpose is and why it needs these wide-ranging privileges.

Because of the security implications of this, I don’t usually review requests for snapd-control, but once the person who reviews them has a chance to look at this, he will certainly ask for more detailed information as I have mentioned. So if you could prepare and provide those details, that may help get this reviewed more easily.

2 Likes
3

@kyleN, @anewman - can someone from your team take a look at this? From the sound of it, it seems like a brand store may be the path forward.

4

@corentin.damman - can you more precisely describe what your snap does and where? Based on the name and the request, it sounds like this is meant to manage ‘lbe devices’ and not ‘arbitrary devices’.

5

@jdstrand - The goal of this snap is to be able to manage devices manufactured and set up at Laborelec (lbe). Those devices will be send to various locations, and we don’t want to maintain a ssh connection to them. The goal of this snap is then to:

  • Synchronize configuration files for other snaps with our file service
  • Install/remove/refresh snaps on the devices
  • Trigger snapctl actions to run other snap hooks

This lbe-device-management snap is then intended to run exclusively on devices from Laborelec - it is a private snap. This means that you must be a lbe-device in order to download this snap (available only if you are logged as lbesoft user on the device). Then, as this snap will always be a private snap, I don’t see any reason to reject the snapd-control interface :slight_smile:

6

Hi @corentin.damman,

As you know, private snaps requires a user to be logged in to the device to access it. And this user has to be either the owner of the snap, or a collaborator, which has full RW access on the snap.

So, imagine, if every device from Laborelec would have RW credentials for an account that can access and change this snap, every human accessing these devices could:

1- change the privacy setting, from private to public
2- upload a new revision abusing the interface, with any malicious content (intentionally or non intentionally).

So granting the snapd-control interface to a snap in the public store is not something that can be done in this case. What Laborelec should consider is getting a brand store, which is designed exactly for this case: there are snaps targeting a specific device model, which does not make sense in to be available in the main store; and the brand store can have a finer control about what interfaces the snaps are granted.

A brand store has also the very desirable feature where your devices would not need any user credentials in it, they will have a custom model pointing to this store with a unique serial and no other device could impersonate a device to access the brand store.

If you/Laborelec decide not to use a brand store, you should really re-consider not using the “private” feature of a snap for this, since (as I mentioned above) in order to access a private snap, owner or collaborator is required, and any of those have full RW access on the snap. Furthermore, user authentication in a device expires, so every user using a device will have to re-login, manually, entering email and password, every time the user authentication (macaroon) expires. Expiration date of user authentication can vary.

Private snaps were designed to be used in an initial phase of development, so a minimal group of users could upload new revisions and test it in a device, but it was not designed, nor it makes sense to be used, as a way of production distribution of your snap.

Regards, Natalia.