Sandboxed application can't communicate with browser extension

Hey, @collanderfleece. That's actually just not going to work, and you'd be best installing 1Password via the distribution's package manager.

To make the connection, we require an SUID app launch all of the browser communication tools. They have to be installed via security.wrappers, which I believe can only be done at the NixOS level. I don't think you can do it with home-manager.

@Savanni what if you're using Nix installed on a foreign distro managed with Home Manager? I have Firefox installed as a Nix package with the 1Password extension and _1password-gui but of course they don't speak to each other

Thank you for letting us know, malcolmredheron. 👋

Ah! Thank you, @Savanni. I'd looked for options, but I forgot to check the unstable tab. I'm not brave enough to switch over to unstable at the moment so I'll excitedly wait for this to arrive in stable.

Hi, malcolmredheron. You can't install 1password as a normal package. You have to enable it in your OS configuration. Look for programs._1password in the NixOS options search. _1password is for our CLI application, and _1password-gui covers the gui desktop application.

I'm really excited to read that the browser extension should be able to communicate with the desktop app in nixos now. I can't get it to work yet, and I've love some help figuring it out.

• I have _1password-gui installed, resulting in /nix/store/i2abcm68fldnivx6ysl6287m7war2k98-1password-8.6.1 as the package path for all of my 1password processes.
• I'm using the 1Password Chrome extenstion with id aeblfdkhhhdcdjpifhhbdiojplfjncoa and version 2.3.3.
• I'm using Chrome stable, installed as /nix/store/1slp1hcclwxkmp72swwxzypa7342bpyr-google-chrome-100.0.4896.127.

.config/1Password/logs/1Password_rCURRENT.log says

INFO 2022-04-27T15:58:19.643 tokio-runtime-worker(ThreadId(7)) [1P:native-messaging/op-native-core-integration/src/lib.rs:293] Active native core integration is awaiting messages`
...
INFO 2022-04-27T15:58:19.645 op_executor:invocation_loop(ThreadId(15)) [1P:native-messaging/op-nm-installer/src/nix_utils.rs:83] Successfully installed all native messaging manifests.


There is nothing current in .config/1Password/logs/BrowserSupport/1Password_rCURRENT.log.

My Chrome extension keeps logging the following to its console:


💫 Looking for desktop app com.1password.1password
background.js:2 📤 Sending <NmRequestAccounts> message to native core <1510133695>
background.js:2 Desktop app port disconnected. Error: Specified native messaging host not found.


I'm really excited to read that the browser extension should be able to communicate with the desktop app in nixos now. I can't get it to work yet, and I've love some help figuring it out.

• I have _1password-gui installed, resulting in /nix/store/i2abcm68fldnivx6ysl6287m7war2k98-1password-8.6.1 as the package path for all of my 1password processes.
• I'm using the 1Password Chrome extenstion with id aeblfdkhhhdcdjpifhhbdiojplfjncoa and version 2.3.3.
• I'm using Chrome stable, installed as /nix/store/1slp1hcclwxkmp72swwxzypa7342bpyr-google-chrome-100.0.4896.127.

.config/1Password/logs/1Password_rCURRENT.log says

INFO 2022-04-27T15:58:19.643 tokio-runtime-worker(ThreadId(7)) [1P:native-messaging/op-native-core-integration/src/lib.rs:293] Active native core integration is awaiting messages`
...
INFO 2022-04-27T15:58:19.645 op_executor:invocation_loop(ThreadId(15)) [1P:native-messaging/op-nm-installer/src/nix_utils.rs:83] Successfully installed all native messaging manifests.


There is nothing current in .config/1Password/logs/BrowserSupport/1Password_rCURRENT.log.

My Chrome extension keeps logging the following to its console:


💫 Looking for desktop app com.1password.1password
background.js:2 📤 Sending <NmRequestAccounts> message to native core <1510133695>
background.js:2 Desktop app port disconnected. Error: Specified native messaging host not found.


Hi @Savanni ,

Would this be a one-time permission that we'd need to give once?

I'm writing this comment on Brave Browser which is also packaged as flatpak, running 1Password Browser extension. I installed 1Password desktop application as flatpak as well. If such administrative assumptions were made, it probably wouldn't work for me. I think my case will be fairly common among Linux users pretty soon. (Chrome recently released on flathub)

I'd happily grant access in such a way only if I'd have to it once. (afterall this is what we do with portals)

One of the things that we try to guarantee is that only the 1Password browser extension and the 1Password CLI can communicate with the desktop application.

We start with the assumption that anything installed by the system administrator is blessed. We're not trying to defend against a root compromise, because we all know that all bets are off once that happens. So, if the sysadmin installed the application, the BrowserHelper it will be in the expected location (which is /opt/1Password on most machines, /var/run/wrappers/bin on a NixOS machine, and within the sandbox location on a Flatpak installation). Additionally, we need the group set (onepassword and onepassword-cli, respectively), and we need setgid enabled.

With these things put together, the Linux kernel tells us exactly which executable is connected to the socket (we assume this is unforgeable without a root compromise), and we know that setgid disables LD_PRELOAD and other shenanigans that may be able to alter the the runtime.

Without these guarantees, we can only protect against rogue applications by requiring a shared secret between the desktop and any client connecting. For 1Password, that is your secret key and your account password.

With Flatpak, we cannot run any of the automated post-install scripts that set the group id and enable setgid bit. Flatpak's post-install script occurs only within the context of the sandbox and has no access to the groups we depend on. And can't create those groups, anyway. You could manually set these things, but you would have to reset them after every single update. That's the kind of breakage that is likely to lead to a lot of extra load on our CS team.

So, here's one solution I can think of. To be up front, I have no idea whether our security team would accept it, though it seems promising.

We reduce the security, allowing any application to connect and query secrets. BUT, if I haven't mis-understood the identity information that the Linux kernel provides (always possible), we will pop up a warning in 1Password identifying the full path to the executable that is trying to connect, and then allow you to decide whether to permit the connection.

Would that be an acceptable compromise?

Hi, tunix. Eventually, yes. Having finally gotten the NixOS version out the door, I've switched my system over to Flatpak so that I can feel the same pain you are feeling until I get this fixed. Basically, what I've done so far is to modify the launcher script so that certain parameters will launch the helpers. However, there's still a lot that I need to do within 1Password.

I'm trying to get there, but it's really hard for me to make the time.