commit 76d988e97e7263cb6daeed98221a369b8cda1f49
parent d40c27d55aa488cbe733834c18bf5d803d361f69
Author: Daniel Barlow <dan@telent.net>
Date: Wed, 11 Aug 2021 22:55:49 +0100
some notes about security
Diffstat:
| M | README.md | | | 68 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-- |
1 file changed, 66 insertions(+), 2 deletions(-)
diff --git a/README.md b/README.md
@@ -8,6 +8,9 @@ security professional, so the best offer I can make for its abilities
is that it *may* be OK. Hence the name "Maybe OK Secret Store"; c.f.
"Pretty Good Privacy", "Actually Good Encryption"
+Status: pre-alpha, i don't use it for anything important yet and I
+don't think you should either.
+
## Installation
make install # defaults to /usr/local/bin
@@ -32,7 +35,7 @@ you have age 1.0.0-rc3 or later
$ moss git init # if you want to share it with other machines
$ moss git remote add me@githost.example.com:/home/git/passwords
-moss keeps its secrets in
+moss keeps its secrets in
* `$MOSS_HOME/store`, if the MOSS_HOME environemt variable exists, or
* `$XDG_DATA_HOME/moss/store`, if the XDG_DATA_HOME environment variable exists, or
@@ -115,6 +118,68 @@ only writing this down because I figured out how to
cd $HOME/.password-store
for i in `find * -name \*.gpg` ;do ( gpg -d $i | ~/src/moss/moss.rb add "${i%.*}" );done
+## Security considerations
+
+Read this section with the caveat that this program has not been
+reviewed by a security professional. I welcome feedback on any of the
+points here, or on any other points that aren't here but should be.
+
+The primary consideration with regard to threat modelling is that
+moss encrypts and decrypts files using age, in much the same way as
+you might otherwise invoke age by hand. If this doesn't fit your
+security requirements, look elsewhere.
+
+* secrets stored in moss depend on the security guarantees provided by
+ age. age is written by Filippo Valsorda, who is a real
+ cryptographer, so this is probably not the part you should be most
+ worried about
+
+* moss expects that your `$MOSS_HOME` is kept on a local filesystem,
+ or at least that the file server is trusted and traffic to it can't
+ be tampered with. Secrets are not signed, so (I think) you cannot
+ detect when an attacker substitutes a secret other than the one you
+ asked for.
+
+* if an attacker can read files on your computer, but you have
+ encrypted the private key, security of your secrets depends on the
+ strength of your passphrase and on their being no relevant bugs in age.
+ moss does not store or see your passphrase in this scenario: it runs
+ age as a subprocess which opens `/dev/tty` directly.
+
+* if an attacker can read files on your computer and you have not
+ encrypted your private key, security of your secrets depends on
+ whether you are using an encrypted filesystem, the quality of that
+ filesystem and/or whether the attacker can gain access to it while
+ it's mounted. I believe that most Linux systems won't unmount it
+ while the screen is locked, for one.
+
+* if an attacker can write files in your store, they can wipe out your
+ secrets or replace them with other ones, and you might not notice
+ (until you try using them, anyway) because secrets are not signed
+
+* if you have any of: insecure buggy virtual keyboards, keystroke
+ loggers, cameras pointing at your keyboard, virtual hosts with
+ compromised hypervisors, then moss won't help you
+
+* `pass edit` uses Ruby's Tempfile class to write a temporary
+ plaintext file containing the secret. According to the Ruby
+ documentation the "filename picking method is both thread-safe and
+ inter-process-safe", so can be relied on to be race-free. It creates
+ the file mode 0600. The file is deleted after the editor exits, but
+ will not be cleaned up if the moss process is killed while the
+ editor is running,
+
+* all cryptographic operations are performed by running `age` in a
+ subprocess. Care has been taken to ensure it uses arrays instead
+ of interpolating values into strings which may give rise to shell
+ shell injection attacks
+
+* reasonable care has been taken to set appropriate file permissions
+ on keys and secrets, so you should be good against other non-root
+ users on your machine
+
+
+
## TO DO
* remove secrets
@@ -123,4 +188,3 @@ only writing this down because I figured out how to
* support re-encrypting a subtree when recipients change
* --help option
* warn or fail if iffy store permissions?
-
