Sandboxed application can't communicate with browser extension

It's part of the security. We found that setuid was the only way that we could store encryption keys for communication in a root-owned keyring in the kernel, and that setgid was the best and most universal way of foiling LD_PRELOAD and other such potential library attacks on the communication helpers.

In any case, this is helpful information. It may be that there are some manual steps that will be needed, but first I'll be adjusting the entrypoint for the flatpak. And also telling 1Password what command to run to launch the helpers when we detect that we're running inside of a flatpak.

As far as I see, it's not possible to run a script on the host after a flatpak package installation.

Hi @Savanni ,

Afaik flatpak apps execute with the running user's permissions. So ideally you shouldn't need to setuid/setgid -- Why do you need this? Maybe there's another workaround for what you need. I'll check whether it's possible to run a script post installation.

tunix I actually have a question.

Is there a way to set setuid and setgid programs inside of a Flatpak, whether automatically during install or via some commonly accepted "hey, run this script after install" process?

I'm just as excited tunix! Keep your eyes peeled for future updates! 😄

Awesome news! I can't wait for this feature to land :) Thank you for digging deeper into this! Please let us know if we can help.. anything at all! :)

I've done some research and it's going to take some modifications to the code. 1Password needs to know where to look for its helper apps. Fortunately, I am familiar with this area and have ideas for how to make it work.

I'm extremely busy at the moment, but I'll see what I can work out in the upcoming weeks.

I apologize, as I have made a significant mistake in my last post.

We're not currently able to support browser integration with Flatpak. I will dig into this next week as it may be possible with some manual installation steps.

"We don't care" is definitely not our stance. The synchronization model we have between client and server would not work in this case. In order to decrypt any of your data, our applications need two halves of a key. We save one half of it (the secret key) in the client applications only, and we never save the other half (your account password) in any form.

With browser integration, you only have to enter your account password, which is half of the encryption key, into the desktop application. The browser is then able to ask the desktop application for any information it needs via a local socket. But since you didn't enter your account password into the browser extension, we have to decrypt your secrets on the desktop and then safely transfer that to the browser. Since we're effectively transferring decrypted data, we had to find ways to be certain that both sides of this socket were unmodified 1Password applications. For a long time, we could only do this via some setuid root and setgid support programs that set up an encryption key via KEYCTL.

Since October, we found a way that the kernel would unforgeably communicate the identity of any application that connected to the other side of a socket. This let us drop the encryption key because now we can be sure of what is on the other side. We still do some of the same checks, but the overall effect is that we were able to enable this feature for Flatpak in late October. We still need the setuid and setgid support programs, but we no longer need to encrypt the socket data.

There are still some limitations with Snaps that prevent us from supporting browser integration, but we are thinking about ways to provide the feature there, too.

I think it's very unfortunate that the official stance here seems to be

this feature cannot work.

which sounds a lot like "We don't care" to me (which hopefully isn't actually true).

I absolutely understand that this might not have a high priority, and that the current architecture of the application might indeed not work from within the Flatpak sandbox. However, given that 1password already has the infrastructure for encrypted synchronization in place, it seems rather implausible that it's really fundamentally impossible to set up a sufficiently secure encrypted IPC channel between the browser extension and desktop application.

Luckily, things are probably not as bleak as the the answer above suggests, cf. https://github.com/flatpak/flatpak/issues/4281

/rant off