[pass] Extending pass with user-defined hooks / add ons
Lenz Weber
mail at lenzw.de
Sun Aug 2 02:21:45 CEST 2015
I made an attempt at implementing it, but before I submit it as a patch,
I would appreciate some feedback on this.
Signature verifying is a bit complicated: verifying if a signature is
correct is simple, but verifying if a signature is made by a certain
key, not so much.
My solution is currently getting the key fingerprints (there may be
multiple as gpg returns the signing key as well as its master key if it
was a subkey) and comparing them to the fingerprints for all possible
receiver keys.
If you have a more elegant solution, I'd be happy to hear it :)
Regards,
Lenz
Am 01.08.2015 um 23:14 schrieb Emil Lundberg:
> In that case, subcommand signatures would probably be a worthwhile
> addition to a subcommand/plugin system. The docs would need a prominent
> statement of what it's intended to protect against, to reduce the risk
> of misunderstanding and subsequent misuse.
>
>
> On Sat, 1 Aug 2015 23:09 Lenz Weber <mail at lenzw.de
> <mailto:mail at lenzw.de>> wrote:
>
> As far as I know, subdirectories can have .gpg-id files that allow
> for directories with different encryption keys and as far as I know,
> some teams are using this functionality to share passwords in a
> team, while each keeping their own private passwords.
> Usually I would assume that they use git submodules for these
> sub-directories, but they could as well use one git repo for
> everything, as sharing encrypted passwords would not leak any
> information (except the file names).
>
>
>
> Am 01.08.2015 um 23:03 schrieb Emil Lundberg:
> >
>> Ok, it is true that signed subcommands would protect you from an
>> attacker who can only add or edit pass subcommands. I guess this
>> is most likely in the mentioned multi-user scenario - an outside
>> attacker with that capability would likely have write access to
>> all of home. So how likely is the multi-user scenario, and is it
>> supported by other parts of pass?
> >
> >
> > On Sat, 1 Aug 2015 22:39 Lenz Weber <mail at lenzw.de
> <mailto:mail at lenzw.de> <mailto:mail at lenzw.de>
> <mailto:mail at lenzw.de>> wrote:
> >
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> > My reasoning behind this is inspired by git:
> >
> > In git, you cannot add hooks to the git repo itself (or
> rather, you can add them, but the user will have to symlink/copy
> them to <repo>/.git/hooks), as in a multi-user git environment, one
> user could add a hook that would compromise another user just at his
> check-out.
> >
> > Assume a multi-user pass repository: some passwords can be
> read by user A, some by user B and some by both. Now user A is using
> a pass hook, and user B knows this (as they share a repo) and wants
> to know the content of a password from user A.
> > Nothing would stop user B from changing the hook that is used
> by A to something malicious, and of course user A should take notice
> that something changed on merge, but let's be realistic: that can
> slip by.
> >
> > So we have a use case where it is absolutely legitimate that
> multiple users can add and/or edit hooks for each other (as they
> sahre a repo, and hooks are part of the repo), and that may be a bad
> thing. Signing commits won't save you here, as user A would always
> accept changes signed by user B. And user B would not need access to
> any executables in PATH to do this attack.
> > This could only be prevented by signing the executable itself,
> therefore stating "I have reviewed this file and trust this file in
> the current state".
> >
> > Of course, all this is only relevant if we are talking about
> the suggested folder ~/.password-store/.hooks/ and the user is using
> git - if the scripts are outside the git repo, signing might not be
> neccessary.
> >
> >
> >
> > Am 01.08.2015 um 17:38 schrieb Emil Lundberg:
> > >
> > > At first I thought signatures was a good idea, but after
> thinking about it I'm not sure they would actually improve security
> in any way. I mean, they would protect you from malicious pass
> subcommands - but if an attacker can write in your home directory,
> or even just a single directory in $PATH, you're owned anyway. With
> full write access, they can add a malicious "pass" wrapper script
> and prepend it to $PATH in .{ba,z}shrc. With write access in $PATH
> they can just add the malicious code without modifying $PATH. Then
> they wait for you to unlock your key with `pass show` and then go
> nuts with the key unlocked in the agent. At this point they can add
> and sign new subcommands as well, and those will be impossible to
> tell apart from authentic subcommands.
> > >
> > > With this in mind, I'm not convinced that any security is
> gained by requiring subcommands to be signed. Instead, users would
> think they're safer than they are, and be less careful with their
> $PATHs. As the saying goes, bad security is worse than no security.
> > >
> > > I say leave it up to the user to keep their $PATH clean,
> because I don't see a reliable way to do it automatically. If git
> pulls are a concern, you can instead ensure that any commits you
> fetch are signed before you merge them.
> > >
> > > /Emil
> > >
> > >
> > > On Sat, 1 Aug 2015 16:58 Lenz Weber <mail at lenzw.de
> <mailto:mail at lenzw.de> <mailto:mail at lenzw.de> <mailto:mail at lenzw.de>
> <mailto:mail at lenzw.de> <mailto:mail at lenzw.de> <mailto:mail at lenzw.de>
> <mailto:mail at lenzw.de>> wrote:
> > >
> > >
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA256
> > >
> > > It may be a good idea to require those hooks to be
> GPG-signed by the pass user to avoid malicious additions to the git
> repo.
> > >
> > >
> > > Am 01.08.2015 um 12:42 schrieb Steffen Vogel:
> > > > Hi,
> > > >
> > > >> What about a system similar to Git[1] where
> subcommands are just
> > > >> exectuables in your $PATH?
> > > >
> > > > Having a „pass-age“ sub-command somewhere in
> $PATH:~/.password-store/.hooks/ ?
> > > > Thats a nice idea :-) I like it.
> > > >
> > > >> This has some benefits over keeping commands in your
> password store:
> > > >>
> > > >> * pass doesn't have to care about special or
> "blessed" directories
> > > >> * Subcommands can be written in any language
> > > >> * It's easy for third party packages to add new commands
> > > >>
> > > >> Plus if you want to keep your passwords and custom
> commands together you
> > > >> can add ~/.password-store/.hooks (or whatever it may
> be) to your $PATH.
> > > >
> > > > Convinced :-) I’d like to keep the addons together
> with my passwords.
> > > > This way, I can sync my add ons using „pass git pull“.
> > > >
> > > > I would say, that we should agree to a hidden subdir
> in ~/.password-store which gets automatically added to $PATH by pass.
> > > >
> > > > Some proposals (which one do you like?)
> > > >
> > > > ~/.password-store/.hooks/
> > > > ~/.password-store/.addons/
> > > > ~/.password-store/.plugins/
> > > > ~/.password-store/.subcommands/
> > > > ~/.password-store/.extensions/
> > > >
> > > > Kind Regards,
> > > >
> > > > Steffen
> > > >
> > > > PS: I will prepare a patch soon (tm).
> > > >
> > > > —
> > > >
> > > > Steffen Vogel
> > > > Robensstraße 69
> > > > 52070 Aachen
> > > >
> > > > Mail: post at steffenvogel.de
> <mailto:post at steffenvogel.de> <mailto:post at steffenvogel.de>
> <mailto:post at steffenvogel.de> <mailto:post at steffenvogel.de>
> <mailto:post at steffenvogel.de> <mailto:post at steffenvogel.de>
> <mailto:post at steffenvogel.de>
>
> >
> > > > Mobil: +49 1575 7180927
> > > > Web: http://www.steffenvogel.de
> > > > Jabber: steffen.vogel at jabber.rwth-aachen.de
> <mailto:steffen.vogel at jabber.rwth-aachen.de>
> <mailto:steffen.vogel at jabber.rwth-aachen.de>
> <mailto:steffen.vogel at jabber.rwth-aachen.de>
> <mailto:steffen.vogel at jabber.rwth-aachen.de>
> <mailto:steffen.vogel at jabber.rwth-aachen.de>
> <mailto:steffen.vogel at jabber.rwth-aachen.de>
> <mailto:steffen.vogel at jabber.rwth-aachen.de>
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Password-Store mailing list
> > > > Password-Store at lists.zx2c4.com
> <mailto:Password-Store at lists.zx2c4.com>
> <mailto:Password-Store at lists.zx2c4.com>
> <mailto:Password-Store at lists.zx2c4.com>
> <mailto:Password-Store at lists.zx2c4.com>
> <mailto:Password-Store at lists.zx2c4.com>
> <mailto:Password-Store at lists.zx2c4.com>
> <mailto:Password-Store at lists.zx2c4.com>
>
> >
> > > > http://lists.zx2c4.com/mailman/listinfo/password-store
> > >
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG v2
> > >
> > >
> iQEcBAEBCAAGBQJVvN55AAoJED87gGHnFM0sVkEH/2rowojY7ipv95xCW4phzYNK
> > >
> f9Ab5RSlAUP8yLdiBWck+rJ788W1/v4gKFSitKytuOSgN/PVZRS7IN/Kaza2RdGv
> > >
> sX/stzL5jirvVfxga28u71xjk+DnQx8y+ImUOYiB3eGz6W59AZh0l9IOAfnlbFTo
> > >
> Nt/ZN/7XXYLJJdsQTDPO79oZFkNnTsK9q9FED8YGEpN7KyeE7g1bVeFATMdEfhze
> > >
> t39Xb6RTFPMwPudID1rQTmAsrPJ315ihgja/66UM3oW9eEXbXXAEIFZPbXp6+b3d
> > >
> fJU0f0KL8tAWpqMajh+1ztzWJBfeR60P4/QqT3X4lLBFacP4g7ON7i91e3Rx184=
> > > =ddwE
> > > -----END PGP SIGNATURE-----
> > >
> > > _______________________________________________
> > > Password-Store mailing list
> > > Password-Store at lists.zx2c4.com
> <mailto:Password-Store at lists.zx2c4.com>
> <mailto:Password-Store at lists.zx2c4.com>
> <mailto:Password-Store at lists.zx2c4.com>
> <mailto:Password-Store at lists.zx2c4.com>
> <mailto:Password-Store at lists.zx2c4.com>
> <mailto:Password-Store at lists.zx2c4.com>
> <mailto:Password-Store at lists.zx2c4.com>
>
> > > http://lists.zx2c4.com/mailman/listinfo/password-store
> > >
> >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v2
> >
> > iQEcBAEBCAAGBQJVvS6WAAoJED87gGHnFM0sdj0H/0fEJ8a2a+Scy1KmttbkzYFb
> > f6EiRn8PSz/bhiA/i2OF602/GjBvmIQ/Jm5GUvp/Pe7AIXQbFdfZeGqBtUE5Ewr+
> > ntAlgSlDSIHf9VZwjozWJXFrfGsVHdo5AUtK1xQd1/az7eK2Q44bxKQj+9uT+x5S
> > qOiJlKgXhhY3BP1qx78pjrXE9zgG53PHrLB6+OwJVnoUKKRwU8uhXcCRP2lyiUDg
> > xc6QRVrr13h0w+irM5s1SpJNGFPMYcb8rYZ3glewmQVLb4DtrKNRw8rPv72ZCIwW
> > KpdPbirAdPbFMsDoAwdSbivSlr2kn4JxHyBtYQIEqeSkHNw+YhrdTH4+l7aR5ak=
> > =IzEe
> > -----END PGP SIGNATURE-----
> >
>
-------------- next part --------------
From 88dbadf04948e010d0566320764a90d209aa9a4b Mon Sep 17 00:00:00 2001
From: Lenz Weber <mail at lenzw.de>
Date: Sun, 2 Aug 2015 02:14:55 +0200
Subject: [PATCH] add subcommand_hook
---
src/password-store.sh | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/src/password-store.sh b/src/password-store.sh
index d535a74..8a7ee4c 100755
--- a/src/password-store.sh
+++ b/src/password-store.sh
@@ -569,6 +569,26 @@ cmd_git() {
fi
}
+cmd_subcommand_hook(){
+ HOOK="$PREFIX/.subcommand_hooks/$1"
+ [[ -f "$HOOK" ]] || return 1
+ check_sneaky_paths "$1"
+ [[ -x "$HOOK" ]] || die "Hook $1 exists but is not executable"
+ [[ -f "$HOOK.sig" ]] || die "Hook $1 exists but is not signed. Please check if the hook really does what you want it to do and then sign it by using 'gpg --output \"$HOOK.sig\" --detach-sig \"$HOOK\"'"
+ signature_fingerprints=$($GPG --with-fingerprint --verify "$HOOK.sig" "$HOOK" 2>&1 | sed -n 's/^.*fingerprint: //p' )
+ [[ $? -eq 0 ]] || die "Signature verification for hook $1 failed. Please check the hook and if it is okay, re-sign it."
+ set_gpg_recipients
+ for recipient in $GPG_RECIPIENTS; do
+ rec_fingerprint=$($GPG --fingerprint "$recipient" | sed -n 's/^.*fingerprint = //p' )
+ if echo "$signature_fingerprints" | grep -q "$rec_fingerprint"; then
+ shift
+ "$HOOK" "$@"
+ exit $?
+ fi
+ done
+ die "Signature of Hook $1 did not match your key(s): $GPG_RECIPIENTS. \n Exiting."
+}
+
#
# END subcommand functions
#
@@ -590,6 +610,6 @@ case "$1" in
rename|mv) shift; cmd_copy_move "move" "$@" ;;
copy|cp) shift; cmd_copy_move "copy" "$@" ;;
git) shift; cmd_git "$@" ;;
- *) COMMAND="show"; cmd_show "$@" ;;
+ *) cmd_subcommand_hook "$@" || { COMMAND="show"; cmd_show "$@"; } ;;
esac
exit 0
--
2.4.0
More information about the Password-Store
mailing list