xi-keyring

commit

9085a6b9e31a33bc132eb89352f91de1c21e10e2

parent

f9fd654d2af37224709c19210ca11701cb55f691

Author

Tobias Bengfort <tobias.bengfort@posteo.de>

Date

2024-04-05 10:39

add README

Diffstat

1 files changed, 61 insertions, 0 deletions

diff --git a/README.md b/README.md

@@ -0,0 +1,61 @@
   -1     1 # xi keyring
   -1     2 
   -1     3 a simple and extensible alternative for gnome-keyring.
   -1     4 
   -1     5 gnome-keyring is tightly integrated into the linux desktop. There are many
   -1     6 other password managers with interesting features. Just to name a few:
   -1     7 [KeePassXC](https://github.com/keepassxreboot/keepassxc),
   -1     8 [Bitwarden](https://bitwarden.com), [pass](https://www.passwordstore.org/), and
   -1     9 [Himitsu](https://sr.ht/~sircmpwn/himitsu/). Unfortunately, none of them really
   -1    10 implement the `org.freedesktop.Secrets` dbus specification, so they cannot
   -1    11 completely replace gnome-keyring. On the other hand, gnome-keyring itself has
   -1    12 accumulated a sizable legacy, which makes it very hard to extend.
   -1    13 
   -1    14 So this project tries to fill the gap:
   -1    15 
   -1    16 -   Work as a drop-in replacement for gnome-keyring for most common use cases
   -1    17 -   Keep the code simple and extensible
   -1    18 -   Experiment with new features
   -1    19 
   -1    20 ## Threat model
   -1    21 
   -1    22 *As the main focus for now is experimentation, there is no fixed threat model
   -1    23 yet. There are some ideas though.*
   -1    24 
   -1    25 With gnome-keyring, secrets in an unlocked collection can be read by a
   -1    26 malicious application that is running on the user's desktop. This does startle
   -1    27 some users, but the developers have repeatedly explained that [there is just no
   -1    28 point in trying to protect against malicious un-sandboxed
   -1    29 applications](https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/5#note_1876550).
   -1    30 
   -1    31 While I am very critical of security theater myself, I feel like there is room
   -1    32 for nuance here. These are some of the **ideas** I want to experiment with:
   -1    33 
   -1    34 -   Prompt the user when an application tries to access a password to provide some degree of observability
   -1    35 -   Prevent malicious applications from taking memory dumps by using [`PR_SET_DUMPABLE`](https://www.man7.org/linux/man-pages/man2/prctl.2.html)
   -1    36 -   Use a yubikey to store the encryption secret off-device
   -1    37 -   Allow to configure access rules (always allow, always deny, prompt) per application
   -1    38 -   Encrypt the meta data
   -1    39 -   Keep the keyring locked as much as possible without impacting user comfort too much. For example, don't unlock automatically on login.
   -1    40 
   -1    41 **I am not claiming that this is or ever will be more secure than
   -1    42 gnome-keyring.** The gnome-keyring developers are much more experienced with
   -1    43 this stuff than I am. For example, they have put a lot of effort into
   -1    44 preventing secrets from being swapped to disk. That is not something I am even
   -1    45 considering (partially because I rely on full disk encryption).
   -1    46 
   -1    47 ## Deviations from the dbus specification
   -1    48 
   -1    49 While this project aims to be a drop-in replacement for gnome-keyring, some
   -1    50 features of the `org.freedesktop.Secrets` specification have been simplified:
   -1    51 
   -1    52 -   There is only a single collection (called "it")
   -1    53     -   Trying to create or delete a collection fails
   -1    54 -   Whether the keyring is locked or not is not exposed
   -1    55     -   All objects present themselves as unlocked
   -1    56     -   The process of unlocking a keyring is transparent for the caller
   -1    57     -   The `Unlock` method fails
   -1    58     -   The `Lock` method still has an effect though
   -1    59 -   Prompts are transparent for the caller. No prompt is ever returned
   -1    60 -   Labels are generated automatically and cannot be changed
   -1    61 -   `Created`/`Modified` is always 0