Keepassxc: Hybrid CLI operation in conjunction with GUI

[riedel]

Summary

2067 shows a use case for using the CLI for many applications. It would be however great not to have 2 user interfaces running at the same time.

With all the advantages for the UX I , however, currently would be against using an unlocked database, because would mean that any application could read out the database while unlocked.

So this is more a discussion item: how would you recommend doing it?

Desired Behavior

It would be great to have CLI access to an unlocked database on the UI without enabling complete silent readout.

The biggest problem when using autotype is to select the correct credentials when using the terminal

Possible Solutions (alternatives, please suggest more)

1. There were some attempts for generic backend (similar to https://github.com/hifi/keepassxc-agent) that I remember using the browser interface (when http was still in use) . Here there would be at least a dialog to allow access. However currently the UI is very limited to browsers. But the binary would be callable by anyone disguising as whoever.
2. Provide dedicated backends that are equivalent to browser. Providing a plugin/backend for https://github.com/microsoft/Git-Credential-Manager-for-Windows would solve quite a few of my use cases (I hope their security model is actually not that exploitable)
3. Encoding the requested "URL" into the window title. This is a bit of effort and not perfect UX when storing new passwords. Also handling popping up windows is IMHO still difficult
4. Autotype support based on clipboard content. I could probably select the relevant password prompt on the shell before I press autotype
5. Dedicated interaction variant similar to the auto-type keyboard shortcut, that uses the command line to passes information about requested key and works like auto-type otherwise...

Context

1. git
2. curl
3. ssh (with password)

[marcthe12]

1 will be great since be possible to unlock before xorg is available. gpg agent is a good example

[riedel]

1 will be great since be possible to unlock before xorg is available. gpg agent is a good example

Interesting: just to understand, if no XOrg or any other window system is available, what keeps you from using the command line variant of keepassxc altogether? (I was more concerned with the opposite case tbh: sth in the line of the git credential manager for windows and askpass)

What is the use case to unlock the GUI from the command line?

I actually like that gpg-agent is splitting things into many simple bits (multiple key entry implementations with or without X,qt,gnome), that would at least allow the same dialog for GUI/non-gui.

But gpg-agent does not really have a GUI itself, does it?

BTW: actually ssh-agent and gpg-agent made me a bit concerned when I suggested this. I like it much better how keepassxc lets me control when to allow access to a password/key (unfortunately not the agent implementation, which IMHO should be rather integrated like in the keepass plugin. BTW this could be easily possible to push out of the program with a hybrid approach)

[marcthe12]

Interesting: just to understand, if no XOrg or any other window system is available, what keeps you from using the command line variant of keepassxc altogether? (I was more concerned with the opposite case tbh: sth in the line of the git credential manager for windows and askpass)

So it can unlocked on login automatically in a script in .profile and later when I startx, I can switch to gui. For mutt its the opposite way. May create an option so unlocking creates an agent which can be reused by other instances without pasword.

[droidmonkey]

I am not in favor of linking the two ways of using KeePassXC. It just adds one more way for data to escape the running process. Further, I doubt greatly there are many users who will even use such functionality.

[riedel]

I totally agree with your concerns and thus wonder if there would be a usable and secure way to still do this (that is why I opened the ticket)

The same arguments (security and usage) go for the ssh-agent integration:

• keys are not protected anymore
• it is only a benefit for some users using command line tools like ssh

IMHO if there would be way to do this smartly, things like the agent stuff but also the browser plugins could go to external programs (no, i will not call them plugins to create more resistance) instead of bloating keepassxc. But I also have no clue atm on how to control or audit who is actually retrieving passwords.

I think there is some valid use cases (scripts, ssh proxy jumps without keys) where I want to keep keepassxc unlocked on the command line instead of having to type in a master password multiple times.

BTW: I had another idea that could maybe ease the workflow: could it work to have a keyboard shortcut that would put a password (anotherone for password) into the clipboard based on the content of the clipboard. Then I probably could simply select the relevant keyword on the terminal, when being asked for input. This would be a pretty lightweight solution. Scripts could also prefill the clipboard and monitor it for change...

[droidmonkey]

Does keepassxc-cli open not fit the bill of keeping the database open on the command line?

$ ./keepassxc-cli open
Resources::DataPath: can't find data dir
Usage: keepassxc-cli.exe open [options] database
Open a database.

Options:
  -q, --quiet            Silence password prompt and other secondary outputs.
  -k, --key-file <path>  Key file of the database.
  --no-password          Deactivate password key for the database.
  -y, --yubikey <slot>   Yubikey slot used to encrypt the database.
  -?, -h, --help         Display this help.

Arguments:
  database               Path of the database.
>

[riedel]

Why have I never used open? Somehow I totally missed it because the commands worked without it. I have to try this for my workflows. I actually would have expected that the shell mode is started with no arguments provided

[droidmonkey]

It does open a shell without any arguments (see the > at the bottom) where you can retype the open command: open database.kdbx

If you have readline installed it will also allow you to use autocomplete.

[Frederick888]

Hi, I've just published a Git credential helper that allows Git to get/store creds from/to KeePassXC. It talks to KeePassXC using the browser extension protocol so you don't need to keep a separate keepass-cli process open (and you also get finer controls, notifications, etc of course). Welcome to check it out: https://github.com/Frederick888/git-credential-keepassxc :)

[riedel]

Welcome to check it out: https://github.com/Frederick888/git-credential-keepassxc :)

I really like this!!! Unfortunately it does not compile for me (on windows) yet (maybe I have some time to learn rust and fix it ;) ).
But I saw also how much work you put into the caller limiting bit, however here are the pitfalls (e.g. allowing a shell binary). Although i am quite entusiastic about the integration part, it might be smart to actually rather start a (sudo-like) session additionally to limit access to actually sth you want.

TL;DR: I like the notification part of git-credential-keepassxc and also the process scoping of if cli open

[Frederick888]

@riedel Really glad to hear that!

it does not compile for me (on windows) yet

Yea, there are a few dependencies I'm not sure if they'd work on other OS's, especially Windows. I almost use Linux exclusively so my hands are tied on this one unfortunately. But anyway you could file an issue in my repo and it'd be great if you could post some build logs as well. (I just noticed that I put prctl, which I used to disable ptrace, into universal dependency. It's been moved into unix-family only. If this is the only offender you can try recompiling the master branch.)

however here are the pitfalls (e.g. allowing a shell binary)

lol that function is just something that I put in place so that it doesn't punch a hole too huge in my password security. However still it may make it easier to integrate with MAC systems like AppArmor, e.g. you can limit access to the config file (but then you'd probably also need to use AppArmor to protect KeePassXC in the first place). I'm no expert about this so if it's a concern to you perhaps it's better to leave the job to some serious hardening software :) Btw you don't have to allow a shell if you are willing to edit the config file manually.

[riedel]

@Frederick888 : thanks, it is great from a usability point of view but creates some nightmares to me regarding security https://github.com/Frederick888/git-credential-keepassxc/issues/5 . Actually the protocol demands the keys to be "securely stored": https://github.com/keepassxreboot/keepassxc-browser/blame/develop/keepassxc-protocol.md#L16

I think what I might be able to do is just create another user for the purpose of accessing passwords and run shell commands as that user or require elevation on windows...

[Frederick888]

Disclaimer: I'm by no means any security expert and what I'm going to say might be completely wrong.

@riedel I don't think KeePassXC's browser extension protocol can provide you any 'complete' security at runtime, and in fact if there's any program that can read/write random files in your system, you've probably already got some issues that are more serious than KeePassXC password security in the first place.

First of all, how do browsers store the keys used by KeePassXC's official browser extension?

1. If you use an older version of Firefox, the key is stored in a JSON file located at $HOME/.mozilla/firefox/<firefox profile>/browser-extension-data/[email protected]
2. If you use a recent version of Firefox, the key is stored in a SQLite db located at $HOME/.mozilla/firefox/<firefox profile>/storage/default/moz-extension+++<extension uuid>^userContextId=<context id>/idb
3. If you use Google Chrome, the key is stored in a binary file located at $HOME/.config/google-chrome/Default/Local Extension Settings/<extension uuid>

None of the files I mentioned above are encrypted and if you've got a malicious program running in your system, it can basically extract the keys without any hassle. And frankly I don't think browsers should even bother encrypting them, as nothing stops malware from bundling a modified browser then just load your entire profile.

So what you have to do to protect your keys? Under Linux, I reckon you'll need at least:

1. Runtime integrity check of all the involved executables
2. MAC, preferably with pre-loaded rules from kernel image/initramfs, to prevent random programs from reading/writing the config files
3. Kernel lockdown, (IIRC this is required) to prevent root user from ptrace'ing the programs (KeePassXC and git-credential-keepassxc have already disabled ptrace by non-privileged users; but unlike git-credential-keepassxc, KeePassXC has also implemented something similar for Windows)
4. Optionally encrypt the config files using a dedicated write-only hardware, e.g. YubiKey, to further mitigate the threats

None of the techniques above are KeePassXC's concern either.

Hence I think what '[the identification key] should be stored safely' is actually talking about is that the cold data must be stored safely, which can be easily done via (full) disk encryption and etc. But heck, even if you do that, someone who's got physical access to your machine can still (theoretically) perform a cold boot attack.

So AFAIU, at the end of the day it's usually just some sort of trade-off between security and convenience, which is also why the browser integration is not enabled by default.

[riedel]

@Frederick888 : thanks for the clarification!!!!!!

I was exactly googling the same things after posting this and getting to think about what this means for the browser. I was coming back here to add that to my comment, when you already commented.

That actually means that none of the current browsers extensions implement the protocol correctly (they could easily use a master key on their end to derive the key).

For the git-credential part it would be easiest to run it suid root and put make the key only root accessible and require root to whitelist programs.

I was somehow assuming that the key was protected in some way inside the browser (wasn't there an implementation of a protocol at some point that actually started the browser to ensure a secure connection). Now I know, that even the browsers don't implement the protocol correctly. Opening a local socket or a local file doesn't seem to be too different security wise, so I don't get the fuzz about this identificatio key thing. Is there a page really doing a security analysis for the browser extension.

[phoerious]

The key only grants the browser permission to request passwords. Unless you have told KeePassXC to allow all requests, you will still be asked for confirmation every time. Where the browser stores this key, is not up to us. It's also important to note that this key has nothing to do with your master passwords and can be revoked at any time.

[marcthe12]

How does git-credential-keepassxc actually do 'limit callers'. This is actually important. since it could be merged into keypassxc for better security.
Also does it work with sandboxed wrappers like flatpak, snap, firejail?

[Frederick888]

@riedel Before I can feel confident to answer your question, I'd appreciate if any of you KeePassXC guys can quickly fact-check my last comment. But I think the problem is that these protocols are designed to secure communications over public networks rather than those between local parties which share the same storage. And in the context of KeePassXC, NaCl is simply used as a method of authentication.

If you've got a bad actor in your system that can freely access files/memory, there isn't much KeePassXC can do to help you no mater how the protocol is implemented I think. Of course 'mitigation' is still possible and as @phoerious said, you probably shouldn't allow a client to access any credential without confirmation if this is a concern. And ACL/SUID sandbox you mentioned certainly can also mitigate the threats to a degree.

---

@marcthe12 Simply put, 'limit callers' in git-credential-keepassxc doesn't work without all the configurations I mentioned in my last comment (it saves a list of allowed calling programs and uid/gid in the configuration file, but one has to secure the file first to make it actually work). It certainly though makes it more complex to hack.

---

I'd like to quote a common question asked by many security experts: 'What is your threat model?' If your threat is introduced by running closed-source software or large complex programs, then sure sandboxing them can help you isolate these potential bad actors; if your threat is introduced by potential physical access (lost device, etc.) to your computer, then you should look at MFA, disk encryption and etc. KeePassXC is unlikely to be the one that's responsible for these issues.

[riedel]

The key only grants the browser permission to request passwords. Unless you have told KeePassXC to allow all requests, you will still be asked for confirmation every time. Where the browser stores this key, is not up to us. It's also important to note that this key has nothing to do with your master passwords and can be revoked at any time.

Totally understood this part! However, I think that the user checking "remember this decision" is not aware of the fact, that any application with read access to the browser profile can from now on get the password ("usable security" should make trade-offs and consequences of user actions transparent)

Revoking and reissuing a key is not much help here, because this decision is even saved because a "local attacker" can retrieve it as often as one likes. Actually not storing the key in browsers that do not have means of secure storage would be better (session keys). All of this would not however work for a commandline utility as discussed. A word of warning that the "SHOULD" clause in the protocol is not fulfilled is IMHO a minimum, however.

Anyhow, I don't want to suggest too many things that might be as ineffective as the current implementation regarding the threat scenario "application with user access rights" (can invoke a debugger etc), if such a threat scenario is not even supported. At the moment there seems to be a lot of "security through obscurity" in the room. To understand if git-credential-keepassxc increases the attack surface IMHO there needs to be better documentation with a defined threat model (which I could not find).