Classic confinement request for TSCR

store-requests classic-confinement
1

  • name: tscr

  • description: TSCR – Top Secret Chrono Crypt is a proprietary multi-platform desktop cybersecurity and cryptography application. It provides text, file and folder protection, multiple encryption profiles, a Secret Vault, secure secret generation, integrity and system tools, multilingual support, licensing, and desktop integration. TSCR is designed as a local-first / offline-first desktop security application.

  • snapcraft: PRIVATE (Store revision under review: OpenID transaction in progress )

  • upstream: PRIVATE

  • upstream-relation: I am the original author, developer, maintainer, and publisher of TSCR.

  • supported-category: None of the currently listed supported categories exactly fits TSCR. This request is submitted under the documented case where the application requires access to host resources / desktop integration that is not currently adequately supported by existing snapd interfaces.

  • reasoning:

    We did not choose classic confinement as a shortcut or because we were unwilling to make TSCR work under strict confinement.

    We first created and extensively tested a strictly confined TSCR build and spent significant effort adapting the existing desktop application to the Snap sandbox. We tested the available Snap interfaces and added the appropriate interfaces wherever they could correctly provide the resources required by the application.

    We were eventually able to make the strict build run, but only after substantial adaptation and testing. More importantly, the resulting strictly confined package is materially degraded compared with the normal TSCR desktop application and with the tested classic-confinement build.

    1. Severe runtime performance degradation under strict confinement

    In our testing, the strictly confined build runs approximately 5–10 times slower during normal application operation, depending on the operation, than the equivalent native/classic build on the same system.

    TSCR is a cybersecurity and cryptography application performing encryption/decryption, file and folder processing, Secret Vault operations, integrity and system operations, secure local storage workflows, and other security-related processing.

    A performance regression of this magnitude is therefore not merely a cosmetic packaging issue. It directly affects normal application use and produces a substantially degraded user experience.

    Publishing such a build would mean that Snap users receive a significantly slower version of TSCR than users of the same official application distributed through other channels such as the native build, DEB and AppImage.

    2. Required KDE Plasma global desktop shortcut integration is unavailable under strict confinement

    TSCR provides desktop-level global F9 / Alt+F9 shortcuts through KDE KGlobalAccel.

    During strict-confinement testing we confirmed that normal session D-Bus communication itself works, but access to org.kde.kglobalaccel, which is required by the existing TSCR global-shortcut integration, is denied by AppArmor.

    We tested the available Snap interfaces and were unable to find an interface that provides equivalent access to the existing KGlobalAccel integration.

    org.freedesktop.portal.GlobalShortcuts is present on the test system, but replacing the existing integration with a portal-specific implementation would require changing the application itself and maintaining a separate Snap-specific desktop integration path. This is not simply a matter of enabling an existing interface.

    As a result, the strictly confined build cannot provide the same existing global desktop integration as the normal TSCR application.

    3. Strict confinement materially changes the desktop/runtime environment expected by the application

    During strict-confinement development we also had to work around Snap-specific differences in the application environment, including the confined home/runtime context versus the user’s actual desktop environment.

    This is especially relevant for TSCR because it is a local-first desktop security application whose normal workflows interact with user-selected files and folders, removable storage, the operating-system credential store, system information, and desktop-level integration.

    We used the available Snap interfaces wherever they correctly represented those requirements. The classic request is therefore not an attempt to obtain unrestricted access merely for convenience.

    4. The classic-confinement build has been built and tested successfully

    After the strict-confinement work, we produced and tested a classic-confinement build of TSCR.

    The classic build provides the expected behaviour of the existing desktop application without the severe runtime degradation and desktop-integration restrictions observed in the strict build.

    Therefore, this request is not based simply on strict confinement being difficult to package.

    We actually built the strict version, tested it extensively, tested the available interfaces, diagnosed the remaining AppArmor/D-Bus limitation, and succeeded in making the application run under strict confinement.

    The problem is that the resulting strict package is not an equivalent production version of TSCR.

    It suffers from substantial performance degradation and cannot provide important existing host desktop integration. For a security application, distributing a materially slower and functionally reduced version only to Snap users would not be a good representation of the application and would provide an unnecessarily inferior user experience.

    The purpose of the classic-confinement request is therefore to allow the Snap distribution to provide the same practical functionality, desktop integration and runtime characteristics as the official TSCR desktop application.

    If snapd later provides interfaces that allow TSCR to achieve equivalent application behaviour and desktop integration under strict confinement, we would be willing to re-evaluate strict confinement.

    Official TSCR website: https://tscr.x10.mx/

:white_check_mark: I understand that strict confinement is generally preferred over classic.

:white_check_mark: I’ve tried the existing interfaces to make the snap work under strict confinement.

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

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

3

This is actually a hard requirement to be considered for classic at all …

The kde framework extension should get this feature added if it is common to use such a thing.

Have you tested on i.e. Ubuntu 18.04, fedora, gentoo, Arch Linux or an old debian installation ?

Classic snaps need to run everywhere, like strict snaps do. The amount of (binary) patching you need to do to not make the host environment accidentally leak into the snap env and vice versa is often enough way harder than adjusting your app to properly work under strict confinement (you need to patch all rpath calls in the binary and make 100% sure that nothing uses the hosts dynamic linker etc etc)

Did you collect any APPARMOR denials during your work on the strict snap that could explain the performance degradation ? Normally there is no such thing since the interfaces give full access to all resources required once they are connected.

4

Thank you very much for taking the time to review the request and for the detailed feedback. It is very helpful. I would like to clarify the points you raised.

Regarding the supported category

I understand your point that fitting into one of the supported categories is normally required for classic confinement.

We deliberately stated that none of the currently listed categories exactly fits TSCR rather than selecting an inaccurate category simply to satisfy that field.

However, as far as I understand the published classic-confinement procedure, it also says that when something falls outside the existing lists, its requirements should be gathered by a senior reviewer and discussed with an architect, after which the lists may be extended. The same procedure explicitly mentions “access to resources not yet supported by snapd” as a possible criterion for classic confinement.

That seems closer to our situation than selecting a category that does not actually describe TSCR.

So, what would you recommend as the correct next step here? Can we continue working through this together in the current review, or do you think we need assistance from a senior reviewer, architect, or another member of the review/security team?

We certainly do not want to bypass the procedure — quite the opposite. At the same time, the technical situation seems reasonably clear, so there is probably no need to involve additional people unless you believe the procedure requires it.

Regarding KDE global shortcuts

We agree that extending KDE framework support would be the preferable long-term solution if this is considered a generally useful desktop integration.

TSCR currently uses KDE KGlobalAccel for its global F9 / Alt+F9 shortcuts. These work normally in the native/devmode/classic environment, while the strict package cannot provide the same integration.

A portal-specific GlobalShortcuts implementation could be developed in the future, but that would require changing the existing application and maintaining a separate Snap-specific integration path rather than enabling the current functionality through an available interface.

Regarding distribution testing

The application/classic package has been tested on KDE Neon, Kali Linux and Debian GNU/Linux 13 (debian:trixie-slim). It is also built through Snapcraft’s Ubuntu-based LXD build environment.

We have not tested it on every possible distribution such as Fedora, Gentoo, Arch Linux or older Debian/Ubuntu releases, and I do not want to claim otherwise.

TSCR is distributed as a self-contained desktop application, so we expect the classic build to work on compatible Linux systems where its runtime/Qt requirements are satisfied. We nevertheless understand your point that classic confinement interacts more directly with the host environment and therefore deserves additional cross-distribution testing.

Regarding strict-confinement problems

Yes, during strict-confinement development we encountered and investigated several concrete confinement/resource problems, including:

  • restricted access involving /proc/<pid>/mounts, affecting filesystem/device discovery;

  • restrictions involving /proc/vmstat;

  • restricted access to DMI/hardware information used by TSCR’s system-information/fingerprinting workflow;

  • restrictions involving cgroup information such as cpu.max;

  • an initial failure to obtain the expected HDD_id as a consequence of the restricted filesystem/system-information path;

  • the need to add and explicitly connect interfaces including mount-observe, hardware-observe, network-observe, password-manager-service and removable-media;

  • an attempted system-observe solution which introduced mount-namespace/host-filesystem problems around /var/lib/snapd/hostfs/boot -> /boot, so we removed it;

  • the confined HOME/runtime context differing from the user’s actual desktop home environment;

  • and the remaining KDE global-shortcut integration problem.

We eventually worked through enough of these issues to make the strict build functional, but making the application technically run is not the same as obtaining a production-equivalent build.

Regarding performance

The performance difference is reproducible and not based only on GUI impressions.

In devmode/classic, TSCR performs similarly to the native application. Under strict confinement we observe a significantly slower startup and noticeably slower general operation.

We also have a concrete repeatable benchmark: with Multi-TSCR performing 10,000 encryption operations, all three encryption profiles produce approximately 5–10× slower results under strict confinement than under equivalent devmode/classic/native execution on the same system.

We have not proven that one specific AppArmor denial alone causes this performance regression, so I do not want to claim that. The confinement/resource problems above are concrete issues we diagnosed, while the performance degradation is a separate empirical result repeatedly observed during testing.

This is essentially why we submitted the request: after considerable work we managed to make TSCR operate under strict confinement, but the resulting package remains materially inferior to the normal application in both performance and desktop integration.

If it would help with the review, we can also make the strict build available again alongside the classic build, so that you can directly compare startup, normal operation, Multi-TSCR performance and desktop integration on the same system.

We can also provide the relevant strict-confinement logs and benchmark results if useful.

Thank you again for the feedback and for helping us determine the correct way to proceed.

1 Like
5

Thank you for that deep dive, note that I am not in the reviewers team but usually just do the preparation work for them to help having all info submitted before the review starts.

The decision to override the missing category is usually done on a case by case basis so the added info in your second post will surely help, let’s see what they will have to say :slight_smile:

1 Like
6

Thank you for the clarification and for helping us prepare the request properly. Much appreciated. We’ll wait for the reviewers’ assessment — hopefully they’ll be as kind and expeditious as you have been. :slightly_smiling_face::smiling_face_with_sunglasses:

7

Hi @tscr,

Thank you for such detailed forum request. Unfortunately, TSCR does not fit into one of the supported categories, we can not proceed with granting classic confinement and this is a strict requirement. In addition, classic confinement is reserved for mature, well-known applications published by mature, well-known entities. As of today, I do not believe TSCR meets those criteria.

8

Hi,

Thank you for the clarification and for taking the time to review the request.

We understand the current Snap policy and the reasons behind reserving classic confinement for supported categories and mature, well-known applications published by established entities.

There is a slightly ironic detail in our particular case: while the TSCR application itself is certainly not yet “of age”, the underlying encryption concept itself quite literally is. :slight_smile:

TSCR is still a new application, and we fully accept that it cannot yet reasonably be described as a mature or well-known product. At the same time, we believe the current policy may be somewhat too indiscriminate toward new and innovative projects that have a legitimate technical requirement for classic confinement.

TSCR is already publicly released through the Microsoft Store and other distribution channels, has undergone repeated testing and malware/security checks during its development and publication process, and is itself a security application whose primary purpose is encryption and protection of users’ data and secrets.

We therefore understand the policy, but would respectfully suggest that Canonical consider revisiting it in the future so that maturity and publisher recognition are not absolute barriers by themselves. A more selective case-by-case path for newer projects — based on technical justification, application provenance, security review and demonstrated distribution history — could allow legitimate new applications to establish themselves without weakening the security goals behind the current policy.

Regarding TSCR, this leaves us with two realistic options: either not publish it through Snap at all, or publish the crippled strict variant.

We have decided to take the second option.

We will therefore publish the crippled strict variant, while clearly informing users that the strict Snap version is functionally restricted compared with the native/AppImage version, does not provide the complete TSCR functionality and performance, and that Snap installation is consequently not the recommended installation method for TSCR.

This is not intended as criticism of Snap confinement itself — strict confinement is doing exactly what it is designed to do — but simply as an accurate description of its practical impact on this particular desktop security application.

If the new strict revision also requires manual review, we hope that review can proceed somewhat faster than the classic-confinement request did.

Thank you again for the review and for the clarification.

1 Like
9

If You run into any problems with the switch to strict confinement, don’t hesitate to ask, we’re here to help :slightly_smiling_face:

1 Like
10

Hey @tscr

Thanks for your understanding!

If it would help with the review, we can also make the strict build available again alongside the classic build, so that you can directly compare startup, normal operation, Multi-TSCR performance and desktop integration on the same system.

It would be great if you can still share both snaps (strict and classic) to try to understand what is causing these performance issues. My gut feeling is that this might be related to some sort of hardware acceleration device being blocked by the sandbox. It would be amazing if we could do something to at least improve it.

2 Likes
11

Hi @jslarraz,

Sorry for the delayed reply, and thank you for offering to investigate this.

The classic revision is still uploaded to the Snap Store, although it was never published after the classic confinement request was declined. The strict revision, however, was withdrawn, so at the moment there is no strict revision available there for a direct comparison.

We are preparing a new strict build now. Your hardware-acceleration suggestion also prompted us to re-check both the GPU/runtime path and CPU feature detection inside the sandbox, since TSCR selects optimized AVX2/SSE4.1 native processing modules at runtime.

If you are able to access the existing unpublished classic revision from the reviewer side, we can upload the new strict revision and leave both available for comparison. If not, please let me know and I can make both .snap files available directly.

The performance difference we previously observed was substantial — particularly in startup and Multi-TSCR operations — while the classic build behaved essentially like the native Linux build.

Thanks again for taking an interest in this. If you can identify what the strict sandbox is blocking or forcing into a slower path, we would very much prefer to publish a properly performing strict snap rather than give up on strict confinement.

12

Hi @jslarraz,

Quick update: we have now completed and uploaded a new TSCR v2.5.1.0 strict-confinement build (revision 3).

The good news is that after the latest runtime/core and Snap packaging changes, the strict build now performs satisfactorily and very close to the native/classic build. We therefore believe strict confinement is now a viable production path for TSCR.

We also reduced the additional interfaces to the minimum actually needed:

  • password-manager-service — required for application startup

  • mount-observe — required for application startup/system-storage identification

  • removable-media — required for normal TSCR file/folder workflows on USB/external storage

  • org.tscr.TSCR D-Bus plug/slot — required by our strict-safe XDG Portal implementation of the F9 / Alt+F9 global shortcuts

hardware-observe and network-observe are no longer required and have been removed.

We tested the exact new build locally under strict confinement with these interfaces connected. Startup, normal operation and the XDG Portal global shortcuts are working correctly.

Revision 3 was uploaded with --release=stable, but it is currently blocked with:

human review required due to 'deny-connection' constraint (interface attributes)

The Snapcraft dashboard also shows that the snap is queued for manual review, and visibility cannot be changed from Private until that review is approved.

If you can help route or expedite the review and the required auto-connect permissions, we would greatly appreciate it. At this point this appears to be the remaining blocker to publishing TSCR as a strict Snap.

One additional Store-side issue remains: the Listing still shows our obsolete description mentioning the previously planned classic-confinement release, even though revision 3 contains the corrected metadata.

Thanks again for your help.

13

Hey folks!

This are great news! Thanks for your effort to make a more secure snap environment. I just saw that you created a new requests for the interfaces, so let’s continue there :slight_smile:

1 Like
14

Thanks @jslarraz — much appreciated.

Yes, let’s continue in the new Privileged Interfaces request.

The strict v2.5.1.0 build is now released and working satisfactorily in our local tests with the required interfaces connected, so the remaining step is to get the required auto-connections approved for a seamless user installation.

Thanks again for your help and for guiding us toward a workable strict-confinement solution. If possible, we’d really appreciate it if you could also keep an eye on the remaining Privileged Interfaces review and help us see this final stage through to completion.

1 Like