TSCR – auto-connect request for password-manager-service, mount-observe, removable-media and internal D-Bus

store-requests privileged-interfaces
1

Hi,

I am requesting the required auto-connections for the tscr snap.

name: tscr

description: TSCR – Top Secret Chrono Crypt is a proprietary, local-first hybrid cybersecurity and cryptography desktop application providing file/folder/text encryption, Secret Vault/password and credential management, secure-value generation and related security tools.

snapcraft: PRIVATE

upstream: PRIVATE

upstream-relation: I am the original developer, owner and publisher of TSCR.

The current strict-confinement build is TSCR v2.5.1.0, revision 3.

We migrated from the previously tested classic build to strict confinement and have now completed runtime testing of the strict package. We deliberately removed interfaces that proved unnecessary (hardware-observe and network-observe) and reduced the requested permissions to those actually needed by the application.

Interfaces requested:

password-manager-service

request-type: auto-connection

TSCR includes a Secret Vault / credentials and secrets management subsystem and uses the system keyring/Secret Service for secure local storage. In our strict-confinement testing, disconnecting password-manager-service prevents TSCR from completing normal application startup; reconnecting it immediately restores normal operation.

This is therefore not an optional integration feature for TSCR but part of its normal secure-storage runtime.

mount-observe

request-type: auto-connection

TSCR performs storage/system identification and disk/mount discovery during initialization and for file/folder security workflows. The interface is used read-only for mount information.

We explicitly tested the strict build with this interface disconnected: TSCR cannot complete startup. Reconnecting mount-observe restores normal startup and operation.

removable-media

request-type: auto-connection

File and folder encryption/decryption is one of TSCR’s primary functions. Users legitimately need to protect data located on USB drives, external disks and other removable storage mounted outside their home directory.

Without this interface, the strict snap cannot access those user-selected files even though they are normal TSCR encryption/decryption targets.

Internal D-Bus connection

Plug: tscr-toggle-client Slot: tscr-toggle-service Bus: session Name: org.tscr.TSCR

request-type: auto-connection

The D-Bus service is internal to the same TSCR snap and is used by our strict-safe XDG Desktop Portal global-shortcut bridge. The portal receives the user-approved F9 / Alt+F9 shortcuts and the helper sends the Toggle request to the main TSCR process through org.tscr.TSCR.

Without the plug-to-slot connection, this desktop integration does not work and the user would have to manually connect the snap to itself after installation.

The well-known D-Bus name org.tscr.TSCR has already been reviewed and granted for revision 3 by @jslarraz.

We have locally tested the exact v2.5.1.0 strict package with these connections enabled. Application startup, normal runtime operation and the XDG Portal global shortcuts work correctly.

Revision 3 has already been uploaded with --release=stable. It is currently pending human review.

We would therefore appreciate auto-connection approval for the interfaces above so that TSCR can provide a normal out-of-the-box installation without requiring users to execute manual snap connect commands.

Thank you.

@jslarraz @ogra

2

Hey folks,

Let me add a link to the previous request just for the record: Classic confinement request for TSCR

As you said, I already granted use of the org.tscr.TSCR well-known d-bus name, as it matches the current policy. The snap now passed automatic review and is published to the store.

First of all, if TSCR is a commercialized by a registered company, I would encourage you to apply for Verified Accounts. It will grant you the green tick icon on all your snaps, so that your users can know that they are consuming the snap from the authoritative source. In addition it will help the reviewers to weight for on some of the auto-connections requests.

password-manager-service

This exposes all credentials stored in the session keyring and therefore auto-connection is (almost) never granted. As per your description, TSCR includes a Secret Vault / credentials and secrets management subsystem and uses the system keyring/Secret Service for secure local storage., my understanding is that TSCR only needs to access credentials that TSCR created previously. In this case, the Secret portal would be the right solution.

If you can clarify whether my assumption is right and the programming language you are using for the interaction with the Secrets store I might be able to provide further insights.

mount-observe

This is most likely required and acceptable. It would be really helpful if you would be able to provide the apparmor denials you observe when running the application with this interface disconnected.

removable-media

As per the Process for aliases, auto-connections and tracks - Snap documentation, users tend to store sensitive information in external devices. Thus, auto-connection is frequently reserved for a reduced range of application (mostly media players, recorders, etc.).

Assuming that TSCR is a desktop application, maybe File Chooser - XDG Desktop Portal may be helpful in this case.

Thanks!

3

This request has been added to the queue for review by the @reviewers team.

4

Thanks @jslarraz — this is very helpful.

Regarding password-manager-service, your assumption is essentially correct, and I should clarify one important point.

TSCR does not use the system keyring to store the user’s Secret Vault contents, nor does it intentionally access credentials belonging to other applications. User secrets are protected separately within TSCR’s encrypted storage architecture, locally and, where explicitly enabled by the user, through encrypted remote storage.

The system keyring is used only for a limited set of TSCR-owned encrypted/runtime security data required for normal application operation.

TSCR is deliberately designed as a genuinely cross-platform application, across multiple operating systems and CPU architectures. It uses the standard Python keyring abstraction as part of that common architecture. Replacing this with a Snap/Linux-specific storage mechanism would mean introducing a separate security architecture solely for one packaging format, which is not a viable direction for the project.

This is why password-manager-service is critical for TSCR: with the interface disconnected, TSCR does not start at all. Reconnecting it restores normal startup and operation.

We fully understand the security concern around access to the user’s session keyring. At the same time, TSCR itself is a security and secrets-management application, the interface is required for its normal operation, and TSCR does not intentionally enumerate or consume credentials belonging to other software.

We also believe that allowing this specifically required interface while keeping TSCR under strict confinement still provides a substantially stronger isolation boundary than moving back toward classic confinement.

For these reasons, we would very much appreciate consideration of password-manager-service auto-connection for TSCR as a justified exception.

Regarding removable-media, the requirement is similarly practical and directly related to TSCR’s core functionality. Users explicitly select files and folders for encryption/decryption, and those files may naturally reside on USB drives, external SSDs/HDDs or other removable storage. TSCR does not require this access in order to scan removable devices autonomously; it is needed so users can protect the data they explicitly choose.

Regarding mount-observe, we can provide the requested AppArmor denial from a test with the interface disconnected.

If it would help with the review, I would also be happy to provide the corresponding native Linux build so you can directly compare normal application behaviour with the strict Snap build.

Ultimately, password-manager-service is the critical point for us. Without a workable auto-connection for functionality that TSCR requires at startup, the strict Snap cannot provide a normal out-of-the-box installation. In that situation, the substantial work invested in migrating TSCR from the previously working classic package to strict confinement would unfortunately become largely pointless.

We therefore hope we can find a way to complete the strict-confinement publication while preserving TSCR’s existing cross-platform security architecture.

Thanks again for taking the time to help us through this.

5

Hey @tscr,

Thanks for your response. Let’s focus on the password-manager-interface for now, as it seems to be the clearest blocker.

The system keyring is used only for a limited set of TSCR-owned encrypted/runtime security data required for normal application operation.

Thanks for clarifying that.

For these reasons, we would very much appreciate consideration of password-manager-service auto-connection for TSCR as a justified exception.

I fully understand your concerns. However, I don’t think there is any way we can grant auto-connection to this interface. Just to illustrate how seriously we take this topic, it was not even granted to the Chromium snap, which is a very well-known project and whose snap is published by Canonical:

It is a shame that Python Keyring does not support the XDG Secret Portal yet. This leaves us with three options:

  • You could contribute support for the Secret Portal to the Python Keyring upstream project.
  • You could use an exception path when running inside a snap and use a wrapper around the official secret-tool .
  • You could rely solely on manual connection. For that, you could check whether the interface is connected during application startup (using snapctl is-connected ) and ask the user to connect it if needed.

While the first option would be amazing, I understand that it may not be feasible. In that case, I would suggest going with a mix of options 2 and 3. I’ll try to sketch something out to showcase how simple it could be.

Would you be able to share what python “keyring” methods are you using to store and retrieve the secrets ?

Thanks!

6

Thanks @jslarraz. I understand your position, I respect it, and thanks not only for the explanation but also for the way you’ve approached this whole thing and genuinely tried to help us find a workable solution.

If you ever happen to be in Serbia, the first beer is definitely on me. :slight_smile:

I do have one personal observation about the keyring policy though. I understand why you protect access to it so strictly, but at the same time I find it a little ironic, because I personally would not consider the system keyring a sufficiently safe place for genuinely sensitive user secrets in the first place.

That is exactly why TSCR does not use the keyring to store users’ secrets at all. User secrets are kept in TSCR’s encrypted Secret Vault, which is the secure place designed for them. We use the system keyring only for a few encrypted TSCR-owned values needed by the application itself, as a secondary/complementary data layer.

So I understand the Store’s position, even if I personally think the protection around this particular interface is stronger than the security value of the keyring itself really justifies.

And thank you for the XDG Secret Portal suggestion. Unfortunately, it is not a platform-agnostic solution, while TSCR is designed to be platform-agnostic across different operating systems and CPU architectures, so we cannot adopt it as TSCR’s general storage solution.

Regarding your suggested mix of options 2 + 3, could you please explain a little more what you have in mind and how you see that working in practice? In particular, I’d like to understand how the secret-tool wrapper and snapctl is-connected would work together from the user’s point of view.

The D-Bus connection used for the shortcuts is already resolved — thank you for approving that.

mount-observe is also required for TSCR to work, and it only provides read-only mount/storage information. If needed, we can reproduce the failure with it disconnected and provide the AppArmor log.

removable-media is simply there so users can select files/folders on USB drives or external disks for encryption/decryption. It is purely user-driven functionality.

So, unless I misunderstood something, am I right in assuming that the keyring / password-manager-service issue is the only major blocker for acceptance of our request?

Once you clarify the 2 + 3 approach, we can quickly decide whether to use that route, use a manual connection flow with a clear launcher/message for the user, or simply direct users who want a seamless installation to the native Linux version from our website.

In any case, I think we should try to wrap this up as soon as possible. Both you and we have already spent quite a lot of time and energy on this, so once we understand the remaining options clearly, we’ll make the decision quickly and finish the job.

Thanks again for all your help.

1 Like
7

I just finished sketching the option 2+3 when I just remembered that there might a simpler solution.

You possibly just need to add following snippet at the application startup:

import keyring
from keyring.backends import libsecret

if "SNAP" in os.environ:
    keyring.set_keyring(libsecret.Keyring())

Essentially, it tells keyring to use libsecret as a backend when running inside a snap, and libsecret already knows how to interact with the Secret portal.

You will also need to add a couple of stage-packages more in your snapcraft.yaml and set the GI_TYPELIB_PATH envvar. For a working example please take a look at snap-secrets-python/snapcraft.yaml at master · jslarraz/snap-secrets-python · GitHub

1 Like