I am requesting classic confinement for our Snap package idio-time.
Technical Reasons:
The application requires access to the GNOME keyring for securely storing and retrieving confidential information, which is not fully supported under strict confinement.
It needs to interact with the X server to get the current active window using the ewmh library, which requires permissions beyond what strict confinement allows.
The application also needs to communicate with org.gnome.ScreenSaver to monitor user activity, which is restricted by AppArmor policies in strict confinement.
Snap Details:
Name: idio-time
Description: idio-time is a user monitoring system application designed to provide comprehensive tracking and analysis of user activity.
(N.B, libsecret would need the desktop plug connected in addition to all the ones below).
For X11, you should be able to do this via the X11 interface, which broadly gives access to X11 sockets and doesn’t mediate much beyond that (X11 is famously hard to secure and the longterm is to use Wayland).
The Desktop, X11 and Screen Inhibit Control interfaces should automatically connect without any extra permissions needed. password-manager-service usually isn’t applicable for autoconnection even with store exception, and would be connected manually by the users (sudo snap connect mysnap:password-manager-service), graphically via the app store, or handled automatically by libsecret where possible.
Hi,
Thanks for the help.
Now I am requesting auto-connection for the password-manager-service interface for our Snap package idio-time.
Technical Reasons:
The application requires access to the GNOME keyring for securely storing and retrieving confidential information, which is crucial for the application’s core functionality.
Auto-connection of this interface is essential for providing a seamless user experience, as manual connection is not user-friendly and could hinder the application’s usability.
Could you please explain how the GNOME Keyring access is crucial for the applications core functionality?
We have password managers that don’t have this interface autoconnected, the preference is to use libsecret which in recent versions handles things securely and is compatible with the sandboxing.
Thank you for your response. I would like to provide more details regarding why the auto-connection for the password-manager-service interface is crucial for our Snap package idio-time.
Technical Reasons:
Security Requirements:
Our application, idio-time, needs to store and retrieve sensitive information such as user credentials and session tokens securely. This is a core part of the application's functionality, ensuring that user data is protected.
The GNOME Keyring, accessed via libsecret and secretstorage, provides a well-established and secure method for managing these secrets, which aligns with our security best practices.
Core Functionality:
The application relies on the GNOME Keyring to manage user sessions and store authentication tokens that are essential for accessing various services within the app.
Without access to the GNOME Keyring, the application would not be able to securely manage these credentials, which directly impacts its ability to function correctly and securely.
User Experience:
Auto-connecting the password-manager-service interface is essential for providing a seamless user experience. Manual connection steps are not user-friendly and could hinder the application's usability, especially for non-technical users.
Ensuring that the interface is auto-connected allows the application to function as intended out-of-the-box, improving the overall user experience and reducing the risk of user error.
What services within the app are these? Could you provide an example?
E.G if a user didn’t connect this manually, what’s the functionality lost in your snap? The interface being auto-connected needs to be balanced against the apps primary functionality and user expectations, what would the user expect to see happen with and without access to the system keyring?
When user logged in, we are storing logged user info(user name, email) along with token(jwt) using keyring. For user activity syncing using api we need the token again for authentication. If a user didn’t connect password-manager-service manually, the user will unable to login to our system. We must need it asap.
Out of interest, given the default on most modern Linux distros is Wayland, not X11, how will this work?
Also, frankly, you’re making a keylogger and spyware. Now, it may well be under contract with a company who want to log keys and spy on their employees - and if that’s legal and contractually okay in that region, fair enough. There are plenty of other companies that do this.
However, when looking at the background of an entity who request classic confinement, the team will almost certainly look at the website link you provided. That website looks pretty bad. I personally wouldn’t trust anything downloaded or referenced from it.
Apologies if this is your personal baby, and you put a lot of time and effort into it. But the site is full of errors, broken links and ‘dodgy’ content.
Being charitable, this whole thing could (at absolute best) be seen as a rapidly thrown-together tech demo by students at a hack-day. At worst it looks like an attempt to subvert the store approval process to get a questionable app in the store.
Perhaps the real answer is somewhere in-between. I mean this with respect and kindness, but if you want someone to install a unconfined key-logger, you need to look a lot less like scammers.
Also, it’s very, very rare for someone to turn up here with a brand new app and ask for classic confinement.
After the first reply , I understand classic confinement is not required for me. And the provided website is still under development. Now I only need auto-connection for the password-manager-service interface. That’s it
Access to the password-manager-interface provides a snap the ability to read ALL existing stored secrets - not just its own. As such, this should never be auto-connected in general. Instead the snap should make use of the libsecret API as suggested by @James-Carroll above which allows the snap to store its own credentials securely but without needing access to the users entire keyring. Also given the concerns raised by @popey above and the complete lack of any sensible description for the snap in the store - https://snapcraft.io/idio-time says
A brief description of your application
A longer description of your Python desktop application.
I am extremely wary of granting such access.
As such, -1 from me for auto-connect of password-manager-service for idio-time.
As @alexmurray said, password-manager interface should not be auto-connected in most cases. Thus, -1 also from me for auto-connect of password-manager-service for idio-time.
Using the secret-portal (via libsecret) should be the way to go as discussed here
