What is the best practice for installing and using Keepass w/ Qubes OS ?
Which VM type, can vault be used, will need usb access for key file, should it be on a standalone vm?
Please let me know a good way to proceed. Thanks.
KeepassXC is already a part of your installation and is available on all of the “pre-canned” virtual machines (Personal Work, etc) including Vault.
I wouldn’t ever use it except on Vault. (In fact, I’d do a lot more than that to ensure you don’t use keepass anywhere else, but that’s a rabbithole I’ll sidestep for now unless you are interested.)
To get the password from KeepassXC on vault, over to (say) some web browser on “Untrusted” first use the copy function in Keepass XC itself to copy to Vault’s clipboard, then shift-control-C to get it onto the special inter-Qube clipboard. Then over in Untrusted, shift-control-V gets the password onto Untrusted’s clipboard, and a normal control-V will paste it into the login box on the browser.
I realized you asked about Keepass, rather than Keepass XC but as far as I know they both read the same password database files.
Hi,
I totally agree.
However, I would recommend creating a dedicated qube:keepass for the database storage and GUI support of the application, and then using keepass only in that qube.
With keepass located in qube:keepass, you can copy passwords to other qubes.
In addition, I recommend setting the network for qube:keepass to “None”.
This way keepass will be completely offline.
Which VM type, can vault be used,
This part is ambiguous to me. Do you mean virtualization
mode, or Qubes VM type?
Virt mode can be any of the possible options,
but the default of PVH is sufficient.
will need usb access for key file,
Ensure that USB passthrough works
with a test vault setup.
should it be on a standalone vm?
It doesn’t have to. AppVM is a fair choice,
provided you don’t compromise the template on which
it’s based.
In terms of securing your usage of Keepass2 or KeepassXC, I would recommend the most important step is creating a separate TemplateVM and only using your keepass app of choice from AppVMs derived from that TemplateVM.
By isolating your keepass app’s TemplateVM from your other TemplateVMs you run less risk of accidentally exposing your keepass database file to risk.
As others mentioned, AppVMs you run any keepass-related application in do not need a network connection so remove that, and clipboard is sufficient for moving secrets out to other qubes for most usage.
I would also add that there is an important concern for any use of encrypted secrets that you should make sure your encrypted secrets can be used by you 10 or 20 years from now. In the case of a keepass database file, you can achieve that by making note of what keepass application did you use to create the database file, what version string was it, and then also use Qube’s backup feature and include the TemplateVM with that keepass application in a backup, not necessarily your regular backup, that you can later access if you need to.
Keepass itself is actually an open standard if I understand correctly, so the database files have fairly good interoperability between applications. However, you will find that different applications have introduced extensions and nonstandard behavior that is not interoperable, so it would be beneficial to make note of what application you actually used and make sure you can always have access to it as well.
These applications are also open source as well, so it is unlikely that they would vanish off the face of the earth, but backing up your TemplateVM is a good idea if you want to explore the model of what could go wrong with mismanagement of your secrets.
Honestly I don’t bother with key files and cannot comment on what would be good practice for dealing with those though. I would suggest you understand that even with disposable VMs, traces of your key file may remain from a forensics stand point, so I sincerely doubt the security of key files on general principle even if in practice they are unlikely to be compromised by such traces. I would only ever use a key file for something I didn’t care about and which I considered adequately secured through “obscurity” rather than actual secrecy, but I am not an expert and could be very wrong.
I had mentioned backups before, but it is also worth mentioning that there can be a risk of corrupting your keepass database file! You need to consider backup strategies very very carefully for a keepass database because a naive approach will lead to over confidence and a lack of awareness of how much actual risk you have!
Keeping Qubes backups of the qube containing your database file can give you something to revert back to, but if you have an old copy of a keepass database file, then the process of data recovery from it is manual and you won’t necessarily know off hand which entries have stale password information and which ones have current information!
Furthermore, in the event of an actual database file corruption, the exact nature of the damage to the file matters as the file can possibly be recovered without having to risk data loss by rolling back to an outdated backup.
An example that happened to me was that, while using Keepass2, Keepass2 had a fault of some sort and subsequently refused to open the database file, which was a problem because any rollback to an outdated backup would not bring back what I was losing.
However, KeepassXC was able and willing to open the database file, and, though I forget the particulars, after saving the file with KeepassXC, keepass2 was again able to open the database file and no data was lost as far as I could tell.
With that said, from the perspective of keeping regular Qubes backups small, I would recommend against using a StandaloneVM. An AppVM’s private image is a much smaller backup, and having the ability to backup the TemplateVM and the AppVM separately is good flexibility that StandaloneVMs cannot provide. Additionally, TemplateVMs will save you space should you ever wish to keep more than one AppVM with a keepass database file in it, so by default I will always choose to use TemplateVMs in Qubes OS.
Make a minimal Debian Template and just do this: SSH client with KeePassXC based on a minimal Debian template - #18 by whoami
You will have a:
- Dedicated AppVM / TemplateVM for KeepassXC (without network connection)
- (reasonable) Secure database (optionally + Yubikey CR) for passwords and OTPs
- Secure split-SSH (keys are stored within your KeepassXC database file)
- Optionally split-GPG (outside KeepassXC but within your vault VM)
This is precisely the rabbithole I didn’t want to jump down with an (apparently) new user. Of course another person came along who wanted a rabbit-hole guide, so I am glad you were here to answer this.
I’ll amplify and expand on this (I hope you don’t mind, whoami).
This is in fact exactly what I did, back in the day. I noticed that the default installation uses the same template for all of the qubes, personal, vault, untrusted, work, etc. which led to the rather interesting situation of a vault qube configured never to be on the internet that had firefox in it, and an untrusted qube that had keepass, which you’d have to be nuts to want to use there. Worse, something like sys-net or sys-firewall have no need of any of these apps, yet they are there, right where a hacker (whose doorway is almost certainly sys-net) can possibly exploit them. (To say nothing of the fact you don’t want your passwords in such a place, not even encrypted in keepass.) When you hear about “reducing the attack surface” this is the sort of thing they are talking about.
(I understand why they did this; it was to make the ISO smaller. Multiple custom templates would have bloated it.)
Technically there are two ways you can get into a slightly better configuration.
One: you can clone the qube you were given, one per appvm, then uninstall what you don’t want in that template. Example, clone debian-11 to debian-11-vault, make vault’s template debian-11-vault, then go into debian-11-vault and remove firefox and libreoffice and…well, all of the big apps in the menu except for keepass. I call this the “stripped down” template. It will likely have a bunch of hidden things you don’t need in it, software whose function is to connect to sys-firewall being an example. But that probably won’t be much of an issue. This is easy, but it’s not the absolute best solution; it’s like an 80 or 90 percent solution.
Or you can do as whoami and I have done, and start with a bare metal template like debian-11-minimal (or debian-12-minimal) and build it up to have what you want. (I call this the “built up from the ground” template.) This is a bit trickier because there are often a lot of “little” packages you need to do things you took for granted, often with totally unrecognizable cryptic names. For example in other qubes you want to use to get to the internet, there will be packages you need to install just to connect to sys-firewall. (Incidentally, sys-net and sys-firewall really don’t need firefox, libreoffice, keepass, etc, at all, either! So you might want to base them on something either built up from the ground, or stripped down, too.) So you will end up with templates you know don’t have extra software on it (100% solution) but you will have to work a lot on it, learning what it is you actually do need on a template, given what that template is going to do.
@whoami
Exposing multiple qrexec services from the same AppVM is not a best practice for security anything!
Each one of those qrexec services introduces a new avenue for the keepass database file or other secrets to be exfiltrated from the AppVM or for the AppVM to be otherwise compromised.
For split-ssh, the qrexec service qubes.SshAgent has absolutely no business being in the same qube as a person’s GPG keys. Anyone putting their split-gpg and split-ssh secrets in the same qube is doing so purely for the convenience of their own backups or their own resource management and not as a best practice for security!
What level of CVE on openssh does one need to witness to understand the benefit of keeping ssh identity agents fully isolated not just for their own safety, but also for the safety of everything else, and in this case, of the keepass database file?
If this thread is only about best practice, I would advise, don’t mix and match any qrexec services for split-* stuff like that on a qube containing a keepass database file one cares about.
The reasoning for lovingly creating separate TemplateVMs (regardless of if they are minimal-derived) is ultimately similar as both seek to isolate the AppVM from complicated interests that the AppVM doesn’t need to risk being conflated with, and that’s the only thing that helps secure anyone’s secrets more here.
Agree, but I have already 20+ AppVM in my list and I prefer to have all my secrets in my secrets AppVM. This is a good compromise imo, therefore it is my best practice. As usual everyone has her/his personal view on this - his/her best Qubes setup.
In Qubes OS words: It is a reasonably secure solution 
Providing advice that introduces additional and unnecessary channels of insecurity when someone requests best practices for the use of something in Qubes is misleading and not at all excused by putting the word my in front of the words “best practice”.
When you say you have 20+ AppVMs in your list, you mean running concurrently?
And if so this is your compromise on conserving system resource consumption then?
Or do you mean menu space and just have a reluctance to create additional AppVMs?
Assuming you meant running concurrently, have you considered alternatives along the lines that normally split-ssh and split-gpg do not need to be up and running 24/7 and could feasibly be isolated into disposable templates and run from disposables with lifetimes tied to the qrexec requests that call for them?
I find myself baffled by your response that this is a “personal view” and everyone has a “personal view” on this. I am aware the forum has a rule against making personal attacks on people, but it seems somewhat chilling to paint your self in those colors the moment someone points out you literally gave someone provably insecure advice. If that’s what passes for security discussion here, I’ll take the ban any day to say how insecure this particular advice in this particular scenario is even if you want to somehow paint it as just a matter of personal views.
@whoami
I would suggest adopting the personal best practice of editing your post to add a disclaimer that following the advice you gave carries a tradeoff between security and the consumption of system resources that exposes the user’s keepass database file to unnecessary risk (unnecessary because alternatives are possible), particularly via exploitation of any ssh client that can keep alive a connection to the ssh identity agent and use it to perform arbitrary code execution in the vault qube at will, possibly at the behest of whatever remote ssh server the ssh client is connected to or was compromised by.
If you want to call that reasonably secure in the disclaimer, I would suggest you find new personal best practices for the term reasonably secure, as in the case of SSH, that is not reasonably secure by any means.
One could argue that the expression best practices only make sense with regard to a particular threat model.
1 Like
@leo one could read the original post in the thread to remind themselves of the scope of the advice requested instead of pretending the world is ineffable and full of convenient face-saving ambiguity.
It should be materially obvious from what has been discussed that advising all new users of Qubes OS to add split-ssh and split-gpg qrexec services to their keepass AppVMs is not a best practice for Qubes OS.
The posters that forget the original request and substitute their own threat models or willingness to compromise for the sake of system resource consolidation are simply hallucinating.
For fucks sake people, one poster gave advice that leads to an insecure setup, then doubled down and called it a “personal view” when it was pointed out that said setup was insecure rather than do the reasonable thing and add a disclaimer to their original post explaining the insecure nature of their recommendation. If you want to all go to town defending that as a best practice, then I joined the wrong forum and am wasting my time here, and I thank you for letting me know.
1 Like
Hi @vingallo, I see the need to get back to you and your original request.
Base on your questions I assume that you are a new Qubes OS user.
Based on your original title I assume that you are looking for “best practices”.
Let me try to summarize:
- Keepass
You should keep in mind that there are 3 versions out:
Keepass, KeepassX, KeepassXC (see the FAQs)
My recommendation: KeepassXC
- Which VM
For a newbie it is ok to go for the default vault which comes with the default installation settings. If you want to increase the security you can setup a dedicated minimal template (i.e. deb-11-m-secrets) and make a dedicated AppVM (i.e. secrets) based on this minimal template. Why doing this: increased security by stronger isolation and reduced attack surface.
My recommendation:
- new user: use the default vault
- advanced user: use minimal template approach.
- Key file
This should work out-of-the-box for the (default) vault. I guess, you have stored your file on an external device. Then you just need to route your USB to your vault (see here). Sidenote, attaching external USB drives to vault could be also could be seen as risk.
A more advanced approach would be the use of a security key (i.e. Yubikey). KeepassXC offers you an dedicated option for this (some explanation are on their KeePassXC FAQs).
@vingallo: Please let us know if this and other explanation of SteveC, Pawelek85, deceiver, kissing are answering your question(s).
Edit: kissing asked to delete this section. (see Keepass best practices? - #17 by kissing)
@anon9706954 's recommendation is: Do not use any qrexec in your AppVM which stores your KeePassXC database since qrexec is a security threat - at least it increases the theoretical attack surface. Which is a fair statement and fine for me. If you are looking for ways to increase the security of your passwords it is always a good practice to try to limit everything to the minimum.*
If you are A. seeing kissing’s threat model as critical to you and B. using ssh-keys then:
- You can simply create second vault (vault-ssh-keys, or secrets-ssh-keys) AppVM
- make sure KeePassXC is installed if you want to have your SSH keys securely stored within an encrypted KeePass file
or if A. and C. using gpg-keys
- simply create third vault (vault-gpg-keys, or secrets-gpg-keys) AppVM
* I have seen a guy who stores all his passwords in dom0 since it has the smallest attack surface. You can guess, this is not nice to use, manage, backup and restore but I wanted to share this as an extreme example. If you have a high threat model this looks like a good - secure - solution.
1 Like
@whoami what ___ possesses you to believe you speak on my behalf, and incorrectly at that? qubes.Filecopy is a qrexec service, so stop making up ___ what I have or have not recommended in this thread. Anyone may bother to read my posts, and you may quote them ___, though an astute reader will not find any ___ sweeping claim as you have ___.
I take particular offense to you treating as a footnote that you seemingly ascribe to me or my recommendation to store stuff in dom0, ___. ___.
@whoami you are the poster that introduced the discussion of split-ssh and split-gpg into a thread whose original scope did not include them or request them or need them, and you have not made any representation but grudgingly that lumping those two qrexec services together with a keepass database file has security implications for that keepass database file until I pointed it out. What ___ is your problem in foisting split-ssh and split-gpg on this matter? You are, if anything, off topic, and at worst, creating confusion that would leave systematic vulnerabilities linked to ssh in the qubes of people that followed your advice in this thread.
I tried to summarizes and got back to vingallo request. Taking into account your concerns about qexec and gave options to him to follow up on his own or come back to us.
I guess, this is a misunderstanding: which stores refers to the AppVM not to qrexec. If not I do not get your point? Please explain what is wrong here and I modify.
Misunderstanding is involved, but misattribution is your primary offense in that instance. ___.
Here is a link to my one and only recommendation post in this thread:
What you represented as my recommendation was both not my recommendation and was incorrect.
What I quoted just there is literally a request to remove everything you attributed to me from your post. ___.
You should not need me to post to clarify any of this. ___.
You seem to think that my posts in this thread stating that your (@whoami)'s recommendation to dump split-ssh and split-gpg in the same AppVM as a keepass database file is inherently insecure is my recommendation in this thread. That is simply incorrect as split-ssh and split-gpg have absolutely nothing to do with this thread’s original post and are off topic and were only brought in by you.
And I’m not going to handhold you through an explanation of how qubes.Filecopy is a qrexec service in the same way as everything else, but a qube that does not use any qrexec service is a rather useless qube for the topic of this thread. I have never made any statement, either in advice to you or on the topic of this thread to strip all qrexec services from a qube. ___.
You are not welcome to summarize my recommendation for me when I have already posted mine separately and it has nothing to do with the ___ security issues yours raises and glossed over under the guise of “personal views”. If you need to represent something I said such that you feel the need to blame or otherwise attribute it, quote it and do not paraphrase. And don’t add those insulting footnotes to attributions or quotes as the effect is to conflate the attributed person with the anecdote in the footnote and that is most certainly not my recommendation whatsoever.
I would welcome moderation that took the entirety of your posts and my replies to them and shoved them into a different thread as off topic as any and all mention of split-ssh and split-gpg is wholly off topic to the original thread, and the “personal views” vs security ___ has made it plain this is not the best place to be looking for actual advice on how to use Qubes OS without having the more user-facing internals of Qubes OS like qrexec just be written off as “here be dragons”.
Ok, agree this makes no sense to not continue like this.
I will flag this for mods. @mods please summarize what is relevant for " Keepass best practices? " that we can close this question. Thank you
For the split-ssh issue within KeePassXC I would be happy to follow up on this since it is an interesting topic for me. Should I open a new thread or do you prefer to split this thread?
Let me just remind everyone that we want to encourage civilized discussions here. Please always assume honest mistakes from others instead of jumping into conclusions regarding their behavior.
If someone made a mistake, please point it out. On the other had if someone has clearly put out information that will put others at risk (doesn’t seem to be the case) please flag it.
Last but not least:
My threat model is not your threat model, but your threat model is OK
Please keep it cool everyone 
4 Likes
This post represents setting up split-ssh in keepass vault qubes as a “best practice”, which is information that puts others at risk.
This post points out why that is insecure and requests that post be edited so that people are aware of the risks they take when they introduce split-ssh or anything into their setups.
This post dismisses security concerns as a matter of “personal views”, which is quite frankly why you will find me fucking annoyed by subsequent posts, including now yours @deeplow , that support such trivialization of the encouragement creation of a systematic and exploitable flaw in Qubes OS users configurations.
I didn’t see anything in the community guidelines about being able to report those posters who may be willfully and knowingly advising people to adopt insecure setups, so what do you mean flag it?
I’m guessing you didn’t actually attempt to follow what was insecure about connecting the ssh identity agent that is resident in the same qube as a person’s keepass database file to whatever qubes a person uses to connect to remote ssh servers outside of the user’s control?
Or did you just want to double down on the “personal views” bullshit as being inviolably sacred while honest attempts to point out mistakes people have made that will put others at risk are unwelcome on the Qubes OS forums?
I doubt you did anything but react to the tone of the posters, which is ostensibly against the community guidelines. I can only presume tone arguing like this is the bread and butter here and you get a lot of “personal views” rebuttals from people who get called out on insecure aspects of their advice and can’t be arsed to take ownership of having given advice that would put people at risk. Thanks for letting me know what kind of place this isn’t.