Sandboxed application can't communicate with browser extension

nmenme
Community Member

I have installed 1Password from the Ubuntu Software Center and installed the accompanying Chromium browser extension. When I launch 1Password, then go to Settings > Browser, I see the following text:

1Password detected that it is a sandboxed application. It won't be able to communicate with 1Password in the browser.

Is this expected and normal?

I understand that Snap packages are sandboxed; it's how I installed both 1Password and Chromium. And I get that 1Password for Linux is still somewhat new (grateful that it exists at all!) so I'm really just looking to find out what the intended experience is supposed to be.

Thanks!


1Password Version: 8.2.1
Extension Version: 2.1.3
OS Version: Ubuntu 20.04.2

«1

Comments

  • SavanniSavanni

    Team Member

    Hi, @nme.

    This is expected. Snap and Flatpak both block certain system calls that we require to set up adequate security between the browser extension and the desktop application. Unfortunately, if either your browser or 1Password is sandboxed. this feature cannot work.

  • wisperwindwisperwind
    Community Member

    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

  • SavanniSavanni

    Team Member

    "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.

  • SavanniSavanni

    Team Member

    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.

  • SavanniSavanni

    Team Member

    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.

  • tunixtunix
    Community Member

    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! :)

  • BlakeBlake

    Team Member

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

  • SavanniSavanni

    Team Member

    @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?

  • tunixtunix
    Community Member

    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.

  • tunixtunix
    Community Member

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

  • SavanniSavanni

    Team Member

    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.

  • tunixtunix
    Community Member
    edited February 16

    I see. Communicating with a root-owned keyring sounds like a violation for flatpak but I'm not really an expert on this. There is a portal to keep secrets inside the user's keychain but I'm not sure that's secure enough for you. I'm also not sure whether the sandbox allows you to communicate with a keyring inside the kernel.

    https://opensource.com/article/19/11/secrets-management-flatpak-applications

  • SavanniSavanni

    Team Member

    Fortunately, we don't need that keychain any more, but may need it again for future features.

    When we originally put up browser integration, though, that keychain was how we ensured that the data was encrypted when crossing the socket and that other applications wouldn't be able to connect to the socket to evesdrop on the connection. The new secrets management that you linked to looks very interesting, though.

    Anyway, we can set that aside. Now it's just a matter of me modifying 1Password to know how to find the helper when inside of a flatpak. After that, I have to add a few parameters to the flatpak entrypoint so that we can launch multiple different executables that are stored within the Flatpak.

    Short answer: I largely know what I need to do. I just have to find the time to do it.

  • IanJSaulIanJSaul
    Community Member

    Yay - this would be a welcome functionality change.

  • illutronillutron
    Community Member

    Is there an ETA?

  • PeterG_1PPeterG_1P

    Team Member

    Hi @illutron, no ETA to share on this yet. But we'll be happy to notify of future updates in our release notes, which are here:

    https://releases.1password.com/

    and news about forthcoming updates will be pinned at the top of the relevant forum channel here as well!

  • ASMadASMad
    Community Member

    Right now I have this issue on Linux - Ubuntu 21.10. Here's the issue: when you need to add another account to the Linux desktop app (at least when you can't get into the first account and hence you had to create the second) you can't.

    And now, my rant because I used to love you(1password) and talk you up to everyone and now you anger me greatly: I've been a 1Password user since Aug 2013 - when we could pay flat fees. When I got a new computer(frame.work - all the love) I found I can't have 1Password without putting all my passwords in the cloud. It scares me shitless to have the passwords that control my life in the cloud. (Yes my local is on the cloud. It's about layers. Someone is going to hack you one day whereas my computer is a no-one you'd have to target specifically.) I'm an engineer and I know too much. I can't even export my existing file and import it on the new computer because you made the app not work without logging into the subscription billing account. So I started the slow, painful process of moving to a browser-based password manager. It's also in the cloud and stores 3 text fields with 0 features, but it doesn't operate on a subscription model and I know their risk audit program is solid and 1password made me dependent on having a password manager. 6 months later I still have to keep going back to the old computer to get passwords. Yet I'm still being charged for 1password every month! I have 0 issue with paying for a software that made my life so easy. I have a real problem with the subscription-ization of modern life and the implications for IP and the model of corporate servitude it depends on. In any case, I went to login to the account that's charging me but apparently you can't reset the password and I (in best practice) made the account password different from my vault and now can't remember what super secret thing my brain came up with for it. So I went to make a new account. I can't log into it in the 1password app on Ubuntu because it still has the old account and no way to add a new one. I figured if I could get the app and the browser, where I'm logged in, to talk to each other the app could pick up the new account. But I ran into this issue. And writing this out I realize that making a new account to be able to cut off the credit card charge on a previous account makes 0 sense. But I'm still so mad that a great software company moved to a subscription model that I started going down this rabbit hole.

    Could I please get confirmation that when I delete the original subscription account I made that the billing will also be turned off for it? I had a client not update the CC information in an AWS account after I handed the project over to them once and I don't want to go through that again.

  • PeterG_1PPeterG_1P

    Team Member
    edited March 15

    Hi @ASMad, thank you for raising these concerns with us. There's a lot to address here; I'll do my best.

    I have this issue on Linux - Ubuntu 21.10. Here's the issue: when you need to add another account to the Linux desktop app (at least when you can't get into the first account and hence you had to create the second) you can't.

    This sounds distinct from what other folks in this thread have reported, which has more to do directly with sandboxing features present in Linux. Let me know if I'm misunderstanding, though. And whatever the cause of your issue, our team will be happy to help you resolve it. You can reach us at [email protected] for in-depth troubleshooting. 👍

    And now, my rant because I used to love you(1password) and talk you up to everyone and now you anger me greatly

    First, thank you for the long-time support - it means a lot to us! And I'm sorry to learn that you're feeling this way about our approach currently. I hope to address your concerns here.

    I found I can't have 1Password without putting all my passwords in the cloud. It scares me shitless to have the passwords that control my life in the cloud.

    I get that. I'm not sure how much you're familiar with our security design regarding this, so forgive me in advance if I'm sharing things you already know. Otherwise, I hope this is helpful. 👇

    It's worth asking, "what exactly is securing your data, when it's in the cloud?"

    In our case, our security experts looked over the options and went with an encryption-based approach. This means that your data (which is present on your local devices, as well as in our servers) is chiefly protected by encryption, not authentication.

    In short, if someone doesn't have both your account password AND your Secret Key, they can't decrypt your data. Since you're an engineer (cool!), I'll provide both the short summary of our security model:

    https://support.1password.com/1password-security/

    as well as our more in-depth technical whitepaper here:

    https://1passwordstatic.com/files/security/1password-white-paper.pdf

    A TL;DR of our model is: "We don't want the security and privacy implications of us being able to decrypt your data. So we have provided no means for ourselves to do so. This also makes things way way harder for an attacker."

    This is even the case in situations where an end user might understandably think that they're somehow decrypting their data on our servers. For example, if you sign into 1Password.com, you can look over your items, and there are your passwords, plainly displayed on the screen. This seems like you're looking at a decrypted version of your data on our servers. Can't we see it if you can see it? Not so! All the decryption happens client-side, in the browser session. We never see your decrypted data, ever. Again, this is by design.

    It's worth pointing out a couple extra additional security-salient things as well:

    1. 1Password has never been hacked
    2. Even if we are hacked, we have designed the app not to share the critical security ingredients - your account password and Secret Key - that are necessary to decrypt your data.
    3. We threat model different type of attack scenarios, and design our infrastructure, the app itself, and our internal practices so that if (or when) a breach occurs, it won't impact the security and integrity of your data, and that issues of availability will be limited as well - because your data is cached locally on your devices, and the decryption process occurs only there.

    Also, regarding audits and other forms of security testing, besides our own internal reviews we are also regularly pen-tested by external security firms. We also just announced the largest bug bounty in Bugcrowd's history here.

    Of course, there's no such thing as completely impenetrable security, but we do our best to raise the standard as high as we possibly can, such that the balance of probabilities that a compromise of user data will happen is very very small.

    I have 0 issue with paying for a software that made my life so easy. I have a real problem with the subscription-ization of modern life and the implications for IP and the model of corporate servitude it depends on.

    I can't really speak to the broader critique here. But I can say that we'd love to make things easy for you again, and that our focus remains on building the most secure and performant app we can, and providing world-class support for you as well. That's part of what recurring revenue from a subscription makes possible. You can probably think of other security-oriented apps that use a similar model, and in any case we intend to keep ourselves in line with customer priorities, first and always. We also find it to be far preferable to other models (like selling customer data) which are incompatible with our ethos.

    I went to make a new account. I can't log into it in the 1password app on Ubuntu because it still has the old account and no way to add a new one.

    We should likely be able to help you with this - you can find our Linux team (including myself) at [email protected] We'll do our best to expedite a solution for you!

    I figured if I could get the app and the browser, where I'm logged in, to talk to each other the app could pick up the new account.

    Ah, now I understand. Your most likely path to success here, if you're sure you can't remember the password for that old account, is to get a successful sign-in on the desktop app with the new account. After which, the browser extension (sandboxing issue notwithstanding) will acknowledge that account and things will work across the board.

    Could I please get confirmation that when I delete the original subscription account I made that the billing will also be turned off for it?

    My understanding is that this is correct, but I'd also be happy to connect you with our Billing team to ensure everything is taken care of. We never want to bill you for an account or service you're not using!

    This one went a bit lengthy, but I thought the concerns you raise here are valid, in addition to the technical snarl, which we'd love to straighten out for you. I hope this conversation goes some way to showing that you're still our priority.

  • ASMadASMad
    Community Member

    Wow squared. Thank you for the time you put into that - definitely above and beyond.

    Before I move to email, as you suggest, brief notes:

    Yes, I'm clear about your security model. The centralization is the risk. You're a better (and known) target in 2022 compared to what you were in 2013 when I bought my first 1password license. Also, the value of even a few vaults > $100K bug bounty.

    Yes, I'm familiar with monetization strategies, selection criteria, their implications, etc. I think it's important to at least have a buy-the-thing outright option and/or standardized formats for full export and import across competitive products.

  • PeterG_1PPeterG_1P

    Team Member
    edited March 25

    Hi @ASMad, my pleasure. Thanks for the considerate reply, as well. Your points here are well-taken.

    About export and import: this is definitely something we're working on improving, so it's likely that the current export / import functionality that exists in 1Password 8 will be expanded going forward. We not only want to make this more flexible, so that folks can more easily move their data where it needs to go, but we think we can do this more securely than the standard .CSV import/export process too. I can't say too much more about this, but we're looking forward to showing what's possible with the new app.

    Thanks again, and best regards from our team!

  • tunixtunix
    Community Member

    Hi @Savanni , it's been more than a month since we talked about this. Should we be hopeful that this feature will make it into a release? :)

  • SavanniSavanni

    Team Member

    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.

  • SavanniSavanni

    Team Member

    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?

  • tunixtunix
    Community Member

    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)

  • malcolmredheronmalcolmredheron
    Community Member

    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.
    
  • malcolmredheronmalcolmredheron
    Community Member

    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.
    
  • SavanniSavanni

    Team Member

    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.

  • malcolmredheronmalcolmredheron
    Community Member

    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.

  • PeterG_1PPeterG_1P

    Team Member

    Thank you for letting us know, @malcolmredheron. 👋

  • collanderfleececollanderfleece
    Community Member

    @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

Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Image
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file