Keepassxc: Hardening Keepassxc with Linux namespaces

Created on 17 Jul 2018  路  3Comments  路  Source: keepassxreboot/keepassxc


Hardening Keepassxc with Linux namespaces.

Expected Behavior


Keepassxc should be able to mount USB stick in mount namespace so that to be the only application able to read files on mounted storage.

Current Behavior


Keepassxc is unable to mount USB stick.

Possible Solution



In my opinion the following steps should be taken:

  1. Install keepassxc with CAP_SYS_ADMIN and configure automounter to ignore USB-stick with selected UUID
  2. Create a mount namespace
  3. Fork
  4. a1. parent process will be responsible for mounting USB-stick with matching UUID
    b1. CHILD PROCESS IMMEDIATELY DROPS CAP_SYS_ADMIN
    b2. Now child process starts main window etc...

I wrote proof-of-concept script. It works on Gentoo/X11/KDE5

Note: It would be nice to avoid CAP_SYS_ADMIN (defacto root). It's possible to create mount namespace in user namespace (unprivileged process can create user namespace), but at this moment it's probably impossible to mount anything without powerful capabilities like CAP_SYS_ADMIN.

Context


I'm pretty sure that most people using the key file want to store it separated from daily-use applications like a web browser but in the same time they want the applications to have access to passwords.
Using the key file mounted in the mount namespace prevents an attacker from reading all passwords via simple file reading.

Operating system: GNU/Linux
CPU architecture: -
Kernel: >=Linux-3.8

Most helpful comment

It requires root access everytime you want to unlock the database, that is why it is unworkable in normal contexts. It encourages running KeePassXC as root which is not a good idea. SELinux would be a one time configuration as root to setup the secure operating environment.

If security is this important to you I would not use a key file at all and just buy a yubikey to integrate with KeePassXC.

All 3 comments

This is not a workable solution. Wouldn't it be far easier to use SELinux or similar restrictions?

@droidmonkey

This is not a workable solution.

Why?

Wouldn't it be far easier to use SELinux

AFAIK SELinux is hard to use.

...or similar restrictions

Other LSM like AppArmor would restrict access to keys but it requires more effort from the user.

It requires root access everytime you want to unlock the database, that is why it is unworkable in normal contexts. It encourages running KeePassXC as root which is not a good idea. SELinux would be a one time configuration as root to setup the secure operating environment.

If security is this important to you I would not use a key file at all and just buy a yubikey to integrate with KeePassXC.

Was this page helpful?
0 / 5 - 0 ratings