Grant KeePassXC access to its config directory

[WhyNotHugo]

Without this, KeePassXC can't save its config and it gets reset on each run.

[rusty-snake]

This will break a lot to everything.

Please test your changes.

keeassxc.profile is intentional a non-whitelisting profile. If you want to change this, you first have to say why and second do it correct.

[WhyNotHugo]

keeassxc.profile is intentional a non-whitelisting profile

I though that if a single whitelistdirective was present, then the profile was a whitelisting profile.

[WhyNotHugo]

Please test your changes.

Works perfect for me. I'd love to hear how this breaks other things.

[rusty-snake]

Where is your database stored? In ~/.config/keepassxc? In /mnt?

[WhyNotHugo]

Where is your database stored? In ~/.config/keepassxc? In /mnt?

In ~/keepassxc, which is present in my keepassxc.local.

[rusty-snake]

Also at a bare minimum you could have looked at the profile and see that there are other paths like ~/.cache/keepassxc.

[WhyNotHugo]

Also at a bare minimum you could have looked at the profile and see that there are other paths like ~/.cache/keepassxc.

Please continue, I honestly don't know where this is going.

[WhyNotHugo]

Do you want me to include the cache path here too?

[rusty-snake]

In ~/keepassxc, which is present in my keepassxc.local.

You see the issues? Everyone will require your keepassxc.local.

You need to test this profile, without other modifications.

[WhyNotHugo]

You see the issues? Everyone will require your keepassxc.local.

What's the alternative? Grant keepassxc access to all of $HOME?

[WhyNotHugo]

If keepass had a "standard" location for its files, I'd use that, but it doesn't.

[rusty-snake]

What's the alternative? Grant keepassxc access to all of $HOME?

Yes. That's what we currently do. If you want to change this, you need to argue why. And how this can be done without to much breakage.

[rusty-snake]

Also your PR title is wrong because keepassxc already has access to it's config directory.

[WhyNotHugo]

If we're going to grant unrestricted access to $HOME, then why are we sandboxing?

[kmk3]

@WhyNotHugo commented on Nov 5:

keeassxc.profile is intentional a non-whitelisting profile

I though that if a single whitelistdirective was present, then the profile
was a whitelisting profile.

A "whitelisting profile" usually means a profile that whitelists something in
the home directory (as opposed to not whitelisting anything or whitelisting
things in system directories).

This distinction is made because while system paths can mostly be known ahead
of time, users may organize their home directories in very different ways, so
it is not always viable to create a whitelisting scheme in the default profile
that would work by default for all users.

Which is why whitelisting profiles are usually made sparingly.

In this case, if a user puts their database in ~/ or ~/Documents (which are
arguably likely to be common places for that), this PR would break keepassxc
for them.

[WhyNotHugo]

I'm fine with adding ~/Documents to this PR too. Not sure about ~ tho; that pretty much negates the filesystem aspect of the sandboxing.

[rusty-snake]

If we're going to grant unrestricted access to $HOME

1. It's not unrestricted, there's still disable-commonc.inc+disable-programs.inc
2. You can harden the profile as much as you like and it contains instructions to do so but we can not enabled them by default.
   • Did you read the comment? It already contains you line.

[rusty-snake]

then why are we sandboxing?

This is up to you.

In the Thread Model of the most of use you will not need to sandbox it because KeePassXC is likely a trusted component as it has access to all your passwords and secrets.

[WhyNotHugo]

Huh, indeed, with a clean profile all of $HOME is accessible. I must have mistrusted and had another issue when setting this up.

It's still quite trivial to escape the sandbox (e.g.: edit neovim's startup file and tell it to execute arbitrary commands), but that's not the scope of this issue.

Sorry for the noise, thanks for the clarifications.

[rusty-snake]

then why are we sandboxing?

Why do we sandbox if >50% of profiles can be escaped?

[WhyNotHugo]

Why do we sandbox if >50% of profiles can be escaped?

I'd assume we both want to reduce that number as much as possible. The fact that there is a clear escape mechanism for KeePassXC (as documented above) kinda negates a lot of its use.

On the topic of hardening this profile, how about:

tmpfs ${HOME}/.config/
whitelist ${HOME}/.config/keepassxc

Wouldn't this effectively result in $HOME/.config only containing the keepassxc subdirectory?

[rusty-snake]

This is also the case w/o the tmpfs.

[kmk3]

@WhyNotHugo commented on Nov 5:

On the topic of hardening this profile, how about:

tmpfs ${HOME}/.config/
whitelist ${HOME}/.config/keepassxc

Wouldn't this effectively result in $HOME/.config only containing the
keepassxc subdirectory?

If you actually tried your suggestion before posting it, you would have your
answer:

$ firejail --quiet --noprofile \
  --tmpfs='${HOME}/.config' \
  --whitelist='${HOME}/.config/keepassxc' find | LC_ALL=C sort
.
./.Xauthority
./.asoundrc
./.bashrc
./.config
./.inputrc

[WhyNotHugo]

Is there any way to mount ${HOME}/.config/keepassxc inside ${HOME}/.config if I'm using tmpfs ${HOME}/.config/?

I think the intent of what I'm trying to do here is obvious: mount an empty tmpfs in .config and mount the external .config/keepassxc inside that tmpfs.

I'm basically looking for something like bubblewrap's --bind.

[WhyNotHugo]

This is also the case w/o the tmpfs.

The whitelist mounts the tmpfs on the top level directory, so $HOME would be empty too.