github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #2899] keepassxc: db is not locked after resume from lockscreen / sleep (dbus) #1813

New issue

Closed

opened 2026-05-05 08:29:08 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

2026-05-05 08:29:08 -06:00

Owner

Originally created by @DevPre24 on GitHub (Aug 11, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2899

Expected behavior: KeepassXC should lock the password DB when the Host OS is going to sleep / the screen is locked.

Actual behavior: After the host is resumed from sleep or the screen is unlocked the keepassxc db is still open. I feel like the app doesn't get the sleep/lock event due to excessive sandboxing, without firejail works as expected.

KeepassXc: 2.4.3-1
Firejail: 0.9.60-1

OS: Arch Linux
Desktop Environment: KDE Plasma 5.16.4

Originally created by @DevPre24 on GitHub (Aug 11, 2019). Original GitHub issue: https://github.com/netblue30/firejail/issues/2899 Expected behavior: KeepassXC should lock the password DB when the Host OS is going to sleep / the screen is locked. Actual behavior: After the host is resumed from sleep or the screen is unlocked the keepassxc db is still open. I feel like the app doesn't get the sleep/lock event due to excessive sandboxing, without firejail works as expected. KeepassXc: 2.4.3-1 Firejail: 0.9.60-1 OS: Arch Linux Desktop Environment: KDE Plasma 5.16.4

gitea-mirror closed this issue

2026-05-05 08:29:09 -06:00

gitea-mirror commented

2026-05-05 08:29:11 -06:00

Author

Owner

@Fred-Barclay commented on GitHub (Aug 11, 2019):

@DevPre24 Can you try starting it with firejail --ignore=nodbus keepassxc?

To other maintainers... if this is in fact related to nodbus then I think it's better to just add a comment in the profile rather than remove nodbus from the profile... any thoughts (from you or @DevPre24 too!)?

@Fred-Barclay commented on GitHub (Aug 11, 2019): @DevPre24 Can you try starting it with `firejail --ignore=nodbus keepassxc`? To other maintainers... if this is in fact related to nodbus then I think it's better to just add a comment in the profile rather than remove nodbus from the profile... any thoughts (from you or @DevPre24 too!)?

gitea-mirror commented

2026-05-05 08:29:11 -06:00

Author

Owner

@SkewedZeppelin commented on GitHub (Aug 12, 2019):

If it is indeed nodbus, it should probably be removed as it does break a security feature of the program.
ie. an attempt at removing the database or key from memory.

@SkewedZeppelin commented on GitHub (Aug 12, 2019): If it is indeed nodbus, it should probably be removed as it does break a security feature of the program. ie. an attempt at removing the database or key from memory.

gitea-mirror commented

2026-05-05 08:29:12 -06:00

Author

Owner

@DevPre24 commented on GitHub (Aug 12, 2019):

I removed the nodbus line from the profile as suggested and now the password manager behaves as expected, locking itself when a sleep/lock event is thrown.

As for the security aspect i would rather expose the dbus instead of keeping the key in memory. This way if an attacker is able to unlock the system at least he won't be able to unlock the db unless he has access to the master password. This also reduces the quantity of information that one might collect through a cold boot attack/memory dump.

@DevPre24 commented on GitHub (Aug 12, 2019): I removed the nodbus line from the profile as suggested and now the password manager behaves as expected, locking itself when a sleep/lock event is thrown. As for the security aspect i would rather expose the dbus instead of keeping the key in memory. This way if an attacker is able to unlock the system at least he won't be able to unlock the db unless he has access to the master password. This also reduces the quantity of information that one might collect through a cold boot attack/memory dump.

gitea-mirror commented

2026-05-05 08:29:13 -06:00

Author

Owner

@rusty-snake commented on GitHub (Aug 23, 2019):

Ways in KeePassXC to lock the db:

manual
on suspend
timeout
window minimized
after autotype

I would comment nodbus since it breaks a security feature (see @DevPre24's post), but not every workflow use this (a stricter workflow would have the db always locked (timeout, manual, minimize) and only unlock if access is requiered), then it would be good for the security to have nodbus.

@rusty-snake commented on GitHub (Aug 23, 2019): Ways in KeePassXC to lock the db: - manual - on suspend - timeout - window minimized - after autotype I would comment `nodbus` since it breaks a security feature (see @DevPre24's post), but not every workflow use this (a stricter workflow would have the db always locked (timeout, manual, minimize) and only unlock if access is requiered), then it would be good for the security to have `nodbus`.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#1813

No description provided.

Rows
Columns