[pass] Extending pass with user-defined hooks / add ons
Emil Lundberg
lundberg.emil at gmail.com
Sat Aug 1 23:14:19 CEST 2015
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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.
-----BEGIN PGP SIGNATURE-----
iQJFBAEBCAAvKBxFbWlsIEx1bmRiZXJnIDxsdW5kYmVyZy5lbWlsQGdtYWlsLmNv
bT4FAlW9NpgACgkQHSBkP9nuM68Vzw/8C+wBg62pl+nzIV6e6IudLctFEVRNNeFw
tD7p++EgR2ZdC5XiDTlIiOynns7bqP0CdJinuzlLblKdxvT8nXlEtk4M5QqGHbmG
R1m/2HGz85W+e93tQzumkUBRGGZBj7IqniX8CvXrh05vEeZZcs/vGyxoUy/XiiE6
3cPDFGRuVDEE6qoKNCe3fbQmB8WN/+DsBsMUcYAgQSsmQo/ggsqLD6kd1d2SUXI4
/XiD82/4j6Ei8CQ+pJUTUfaOu0y/LAxgmaxse/IEgX7VrdwC9szm42FBsoTEZ9Jg
4pk0IZ8r9G5AIOQhNpaF0PJ0xD3fDrCU5Kayqp2xZpdqKU8RKZSANT0nB1lQaxq7
RE5y66bxRJoB1+4QY4t2uHKXgcNEEEvK8MB8cZtEdjrT/cdDgSbSTHZ7x3l//riJ
Q5EHYe1dwDnIw5selty5eKUpvhp6cBYUPZ8jrMqss7cnJsdtjF3szUjTOUoMT0rd
9n99kKpJse0dqBqtnOkFGl1oUTRL18cFhVd0xXbrOAKTLgZS4y2d/gl+3zF50nYy
onAbkFWZ5N46S5gwemKTd+K7tta8CcSz6k9czJuoAt3vreTMzLw2fIWhcQS2jY1j
UGsGv0iI/+352G2Wi6tYhrg/9W7nzOXdynMltpC+eV5r7rMLQoi69W/YulyRjII4
L27EM42JOOs=
=+nBi
-----END PGP SIGNATURE-----
On Sat, 1 Aug 2015 23:09 Lenz Weber <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> <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> <mail at lenzw.de> <mailto:mail at lenzw.de>
> <mail at lenzw.de> <mailto:mail at lenzw.de> <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>
> <post at steffenvogel.de> <mailto:post at steffenvogel.de>
> <post at steffenvogel.de> <mailto:post at steffenvogel.de>
> <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>
> <steffen.vogel at jabber.rwth-aachen.de>
> <mailto:steffen.vogel at jabber.rwth-aachen.de>
> <steffen.vogel at jabber.rwth-aachen.de>
> <mailto:steffen.vogel at jabber.rwth-aachen.de>
> <steffen.vogel at jabber.rwth-aachen.de>
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Password-Store mailing list
> > > > Password-Store at lists.zx2c4.com
> <mailto:Password-Store at lists.zx2c4.com> <Password-Store at lists.zx2c4.com>
> <mailto:Password-Store at lists.zx2c4.com> <Password-Store at lists.zx2c4.com>
> <mailto:Password-Store at lists.zx2c4.com> <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> <Password-Store at lists.zx2c4.com>
> <mailto:Password-Store at lists.zx2c4.com> <Password-Store at lists.zx2c4.com>
> <mailto:Password-Store at lists.zx2c4.com> <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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/password-store/attachments/20150801/dc720bb0/attachment-0001.html>
More information about the Password-Store
mailing list