Autoconnect ‘browser-extension-connector' plug for 'passy'

store-requests
1

Hello!

Passy is an open-source password manager application.

Recently, a browser extension has been released. The browser extension requires a connector, which is using native messaging to pass user data between the main database and the browser extension. In order to set up the native messaging connector, a native messaging manifest (a JSON configuration file) needs to be saved under native messaging paths for various browsers.

Here’s the plug itself, listing all the requested directories:

browser-extension-connector:
  interface: personal-files
  write:
  - $HOME/.mozilla/native-messaging-hosts
  - $HOME/.config/microsoft-edge/NativeMessagingHosts
  - $HOME/.config/google-chrome/NativeMessagingHosts
  - $HOME/.config/chromium/NativeMessagingHosts
  - $HOME/.config/BraveSoftware/Brave-Browser/NativeMessagingHosts

Would it be possible to arrange an auto-connect for this plug?

Thank you.

1 Like
2

Hi @glitterware,

Auto-connect with write access to these locations requires some consideration as it could lead to a sandbox escape given the browser will execute the command specified in the manifest, unconfined.

Prior posts regarding the same topic can be found in postman-agent classic, in particular comment 10, and also here: system-files under .mozilla/native-messaging-hosts

@jamesh, I’d be curious to know if you have any more thoughts on the topic, having weighed in previously.

If there’s no better solution, we will vote and likely request publisher vetting as per the process for granting classic confinement, as this ends up being of similar significance.

1 Like
3

Hello @dclane!

I apologize for my initial lack of verbosity regarding this.

I will post several messages below, each containing more information regarding the request (can’t post all in one message because new posters not allowed to have more than 2 links per post).

1 Like
7

I must note that, as a matter of fact, I would be much more comfortable with having this plug instead of classic confinement. This is largely because Passy CLI is much easier to manage than the rest of the Passy application, which makes Passy CLI more secure. This does not mean that we’re not trying to make Passy as secure as we possibly can, but security is not just in quality code, it’s also in confinement.

1 Like
8

I believe it would be possible to prevent confinement violation entirely if I configured the snap to run a shell script that, when supplied an argument, would run Passy CLI. This way both Passy CLI and Passy desktop application would run in confined mode with no possibility of sandbox escape.

1 Like
9

Passy modified to allow for Passy CLI to launch in confined mode.
https://github .com/GlitterWare/Passy/commit/e0679af2b9ba03ccecd54e95bfcdb0505d9d5d26
(link is garbled because the forum does not allow GitHub links)

Here’s the summary of the relevant changes made:

  • linux_assets/passy_launcher.sh - passy_launcher.sh is the new snap entry point.
    #! /bin/sh
    cd $(dirname $0)

    if [ "$1" ] ; then
      $@
    else
      ./passy
    fi
  • lib/passy_cli/bin/snap_native_messaging_launcher.sh - Script for running native messaging launcher in confined mode. Used instead of passy_cli_native_messaging.sh when Passy is ran as a Snap:
    cd $(dirname $0)
    snap run passy $PWD/passy_cli_native_messaging.sh
  • lib/screens/splash_screen.dart - Using snap_native_messaging_launcher.sh instead of regular launcher to allow for confinement.
    if (Platform.environment['SNAP_NAME'] == 'passy') {
      String snapCopyPath = tempCopyDir.path +
          Platform.pathSeparator +
          'snap_native_messaging_launcher.sh';
      return await File(original.parent.path +
              Platform.pathSeparator +
              'snap_native_messaging_launcher.sh')
          .copy(snapCopyPath);
    }
1 Like
10

I am reposting my old messages containing further information yet again because they were apparently flagged as spam.

Passy connector manifest file

{
  "name": "io.github.glitterware.passy_cli",
  "description": "Passy CLI",
  "path": "",
  "type": "stdio",
  "allowed_extensions": [
    "glitterware.passy_browser_extension@github.io"
  ],
  "allowed_origins": [
    "chrome-extension://lndgiajgfcgocmgdiamhffipffjnpigl/",
    "chrome-extension://khcfpejnhlonmipnjmlebjncibplamff/"
  ]
}

The two allowed_origins extensions are:

  1. Chrome Web Store.
  2. Edge Add-ons.

respectively. Both extensions belong to and are maintained by GlitterWare.

Browser extension

The extension source code can be viewed at: https://github .com/GlitterWare/Passy-Browser-Extension

Passy CLI

Passy CLI is the command-line tool that allows for communication between the browser extension and user’s private database. Passy CLI is created and managed by GlitterWare.

Passy CLI does not download or execute any foreign code during its runtime.

It must be noted that no passwords or any other personal information can be accessed through Passy CLI without a proper password as all data stored by user is encrypted with AES512 SIC encryption. The password, when provided, is never stored on disk and is only available in program memory for the lifetime of a Passy CLI process or until when the user signs out via the browser extension.

The connector source code can be viewed at: https://github .com/GlitterWare/Passy/blob/dev/lib/passy_cli/bin/passy_cli.dart

Passy CLI help command printout:

image
image623×1023 153 KB

1 Like
11

Looking back at it I realize that perhaps its best to just allow the installation instead of autoconnect. I would be very glad if that is possible.

1 Like
12

Hello,

Thanks so much for all the detailed information. In this instance, it seems appropriate to grant use of personal-files for the above listed directories, especially without auto-connect, so that’s a +1 from me. It is still prudent for us to perform publisher vetting though, as once the declaration is granted it applies to future versions which of course may change behavior.

@advocacy, are you able to perform vetting please, as we have done with other requests for these specific browser extension personal files accesses. Once that is complete I will grant the declaration.

2 Likes
13

+1 from me for use of (but not auto-connect) of a personal-files instance with write access to the specified paths. However, I wonder if perhaps this should be renamed to native-messaging-hosts or similar to make it clearer what the purpose is to a user?

2 Likes
14

Hello @alexmurray!

Done, renamed browser-extension-connector to native-messaging-hosts for Passy revision #18.

1 Like
15

@glitterware What is the official page for your project please?

1 Like
16

@Igor
Official code repository - https://github.com/GlitterWare/Passy
Official website - https://GlitterWare.GitHub.io/Passy

1 Like
17

+1 from me, I verified the publisher.

1 Like
18

+2 for, 0 against. Granting personal-files interface without auto-connect , named: native-messaging-hosts having read/write permission on mentioned files. This is now live

Thanks

1 Like