Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

enpass: fix install to work with browser extensions #21082

Closed
wants to merge 1 commit into from
Closed

enpass: fix install to work with browser extensions #21082

wants to merge 1 commit into from

Conversation

guillaumekoenig
Copy link
Contributor

Motivation for this change

Enpass is a password manager. Browser extensions in Chrome and Firefox talk to it via websocket, but currently aren't working in NixOS. The issue comes from Enpass looking up the browser process through lsof, with argument the port from the client side (the browser).

Enpass requires lsof to be installed in /usr/bin in order to function correctly. Because the path is hardcoded inside Enpass binary, we try to wrap it in a user fhs compliant environment. Unfortunately this is not sufficient. NixOS uses Linux user namespaces to implement the fhs env, with restricted access to /proc/*/fd/* in particular. This prevents lsof to function fully.

This patch bypasses the restriction by talking to lsof outside of the user namespace via named pipe. The browser extensions for Enpass are now working. However a better fix might be to lessen the restrictions in NixOS user namespaces, if appropriate.

Can somebody help with this ? A way to reproduce is by creating a fhs user environment with nix-shell, running it with this shell.nix in the current directory :

{ pkgs ? import <nixpkgs> {} }:

(pkgs.buildFHSUserEnv {
  name = "test-user-namespacing";
  targetPkgs = pkgs: with pkgs; [ lsof strace ];
}).env

Outside of the namespace, lsof sees Firefox connections :

[guillaume@nixos:~/Downloads]$ lsof -i|grep firefox
firefox    1149 ...

Inside of it it doesn't, strace showing permission denied errors :

[guillaume@nixos:~/Downloads]$ nix-shell shell.nix 
test-user-namespacing-chrootenv:guillaume@nixos:~/Downloads$ lsof -i|grep firefox
test-user-namespacing-chrootenv:guillaume@nixos:~/Downloads$ strace lsof -i 2>&1 |grep /proc/1149/fd
open("/proc/1149/fd", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4
readlink("/proc/1149/fd/0", 0x7ffec4e23740, 4096) = -1 EACCES (Permission denied)
open("/proc/1149/fdinfo/0", O_RDONLY)   = 5
readlink("/proc/1149/fd/1", 0x7ffec4e23740, 4096) = -1 EACCES (Permission denied)
Things done
  • Tested using sandboxing
    (nix.useSandbox on NixOS,
    or option build-use-sandbox in nix.conf
    on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • Linux
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

@mention-bot
Copy link

@guillaumekoenig, thanks for your PR! By analyzing the history of the files in this pull request, we identified @RonnyPfannschmidt to be a potential reviewer.

@Mic92
Copy link
Member

Mic92 commented Dec 11, 2016

If it is only about redirecting executable, you can also use libredirect instead of namespaces which wraps around execve with LD_PRELOAD.

@guillaumekoenig
Copy link
Contributor Author

It looks like libredirect should do the trick. I'll update the patch soon. Thanks for the tip!

@guillaumekoenig
Copy link
Contributor Author

I updated the branch following your directions. In the end /usr/bin/lsof is not hardcoded in the binary as I had previously thought. Prefixing the lsof path to the PATH environment variable suffices.

There is a twist however, the main app (Enpass) checks that the helper binary (EnpassHelper) is the one expected. It makes sure it has not been tampered with by computing its sha256 sum (see https://discussion.enpass.io/index.php?/topic/104-solved-enpass-52-browser-extension-doesnt-work-on-archlinux/). It fails in our case since we fix the dynamic linker path, modifying the binary. Using libredirect does the trick : the open call for the helper binary is redirected to a copy that has not been tampered with and the check succeeds. The browser extension is then working correctly.

Interestingly, the execve call is not impacted by the redirection (which is what we want, when executed we want the version with the dynamic linker's path fixed). Only the open call is redirected.

@grahamc
Copy link
Member

grahamc commented Dec 30, 2016

This works great, thank you. I'm merging and backporting to fix this behavior on stable, too.

@grahamc
Copy link
Member

grahamc commented Dec 30, 2016

Merged in 0465b14 and backported at a485c8a. Thank you!

@grahamc grahamc closed this Dec 30, 2016
@guillaumekoenig guillaumekoenig deleted the fix-enpass-browser-extension branch June 13, 2017 20:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants