1

I would like to be able to secure a KDBX key file in my $HOME, so that nobody except keepassxc (and root) can access it, excluding even myself.

My only approach is to use the setgid bit on the executable/s and give the key file corresponding group membership but unfortunately, keepassxc's GUI is a GTK+ application, that does not like setuid or setgid bits and terminates itself, when detected.

To setup a test environment with a dummy KDBX vault and a key file:

sudo addgroup keepassxc

sudo chgrp keepassxc $(which -P keepassxc)
sudo chmod g+s $(which -P keepassxc)

# to revert back afterwards:
# sudo delgroup keepassxc
# sudo chgrp root $(which -P keepassxc)
# sudo chmod g-s $(which -P keepassxc)

# create test files
keepassxc-cli db-create -p -k key.file test.kdbx
chmod -rwx,g+r key.file
sudo chown root:keepassxc key.file

# access test
keepassxc --keyfile key.file test.kdbx # should succeed
sha256sum key.file                     # should fail

but, like i said, the keepassxc GUI terminates with

Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.

(process:102257): Gtk-WARNING **: 19:45:45.157: This process is currently running setuid or setgid.
This is not a supported use of GTK+. You must create a helper
program instead. For further details, see:

    http://www.gtk.org/setuid.html

Refusing to initialize GTK+.

I refuse to fiddle around with keepassxc any further. There are good reasons for the restriction of setu/gid bits for sure.

Do you know a solution for my approach? Is it even preferable?
Is there an easy template/solution for mentioned helper program? Bash only?
Are there better ways to achive my goal of limited file access to a single executable?

Lars
  • 23
  • 4
  • Wrap it in a script (or function) that uses `sg` to set the group? – muru Feb 19 '23 at 09:03
  • Thank you @muru for sending me down a rabbit hole towards a working solution. Using a script/function that uses `sg` has two issues. 1) scripts can’t have `setuid/gid` bits set, they usually get discarded. 2) `sg` requires a password unless the user is part of that group too. If so, a user could execute _any command_ which would defeat the purpose of limit it to a single one. – Lars Mar 04 '23 at 13:17

1 Answers1

1

After some digging and thanks to @muru, i found a working and seemingly secure solution.

Use sudo to allow group switching for a specific user and host for a specific command. There is no need to change permissions on the keepassxc binaries.

After setting up group and key file (see code block in the question above), create a new sudoers file like:

# creation
echo "$USER $HOSTNAME=(:keepassxc) NOPASSWD:NOEXEC:NOFOLLOW: /usr/bin/keepassxc" \
| sudo tee /etc/sudoers.d/keepassxc

# validation
sudo visudo -sc /etc/sudoers.d/keepassxc

This allows $USER to execute the command /usr/bin/keepassxc only with the group membership (:keepassxc). The command string has to be exact, so if you want to pass additional arguments to keepassxc some day or change the absolute path, you have to reflect that in the sudoers file too or get rejected by sudo.

The final command to launch keepassxc from an unprivileged $USER environment is sudo -g keepassxc /usr/bin/keepassxc, which could easily be an alias.

Lars
  • 23
  • 4