Classic confinement request: rustconn

store-requests classic-confinement
1

RustConn requires classic confinement because existing interfaces cannot provide the necessary access:

1. SSH client functionality:

  • Execute ssh binary with full argument passing
  • Access SSH agent socket (SSH_AUTH_SOCK)
  • Read/write ~/.ssh/known_hosts
  • Read ~/.ssh/config for host aliases
  • ssh-keys interface only provides read access, not agent or known_hosts write

2. External protocol clients:

  • Must execute host binaries: xfreerdp, wlfreerdp, vncviewer, remote-viewer
  • Cannot be bundled (complex dependencies, distribution-specific)
  • No interface allows executing arbitrary host binaries

3. Cloud/Zero Trust CLI tools:

  • Must execute: aws, gcloud, az, oci, tsh, tailscale, cloudflared, boundary
  • Each has credential stores in $HOME (~/.aws/, ~/.config/gcloud/, etc.)

4. Secret manager integration:

  • KeePassXC proxy socket
  • Execute bw (Bitwarden CLI) and op (1Password CLI)
  • KeePass databases in arbitrary user-chosen locations

Interfaces tested:

  • ssh-keys — read-only, no agent, no known_hosts write
  • personal-files — cannot cover arbitrary paths
  • network — works but insufficient alone

Similar approved classic snaps: remmina, termius-app, filezilla

I understand that strict confinement is generally preferred over classic.

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

2

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

3 
ogra@anubis:~$ snap info --verbose remmina|grep confinement
confinement: strict
ogra@anubis:~$

Not sure what makes you think Remmina uses classic confinement but none of the remote viewer/manager snaps do use classic today …

Please also note that it is a hard requirement for getting classic confinement granted at all that you pick a matching category from the supported categories list on:

some made up category like “ssh-client + remote-access-client” is not acceptable …

To my knowledge there is no category that would match your type of application though …

4

Hey @totoshko88

I agree with @ogra . Also ,I don’t think there are technical reason supporting this request.

1. SSH client functionality:

  • Execute ssh binary with full argument passing

You should stage ssh binary

  • Access SSH agent socket (SSH_AUTH_SOCK)

This is intentionally not allowed, otherwise the snap can use all ssh keys loaded in the agent. I think that unmediated access to the agent should not be allowed. See Ssh-agent plug request - #4 by jdstrand

  • Read/write ~/.ssh/known_hosts

This could be granted via personal-files, but maybe the snap should manage its own list of know_hosts

Read ~/.ssh/config for host aliases

This is allowed by ssh-keys

2. External protocol clients:

  • Must execute host binaries: xfreerdp, wlfreerdp, vncviewer, remote-viewer

  • Cannot be bundled (complex dependencies, distribution-specific)

  • No interface allows executing arbitrary host binaries

This is explicitly listed under unsupported reasons in Process for reviewing classic confinement snaps : dependent software only available on host (ship in instead snap (eg, stage-packages, build from source))

3. Cloud/Zero Trust CLI tools:

  • Must execute: aws, gcloud, az, oci, tsh, tailscale, cloudflared, boundary

Again, they should be staged.

  • Each has credential stores in $HOME (~/.aws/, ~/.config/gcloud/, etc.)

Access can be granted via `personal-files` if appropriate

4. Secret manager integration:

  • KeePassXC proxy socket

Why is this needed?

  • Execute bw (Bitwarden CLI) and op (1Password CLI)

They should be staged

  • KeePass databases in arbitrary user-chosen locations

keepassxc snap itself is not classic (keepassxc/snap/snapcraft.yaml at develop · keepassxreboot/keepassxc · GitHub)

2 Likes