[pass] Extending pass with user-defined hooks / add ons
Lenz Weber
mail at lenzw.de
Sat Aug 1 23:09:26 CEST 2015
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>> 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>> 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>
>
> > > 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>
> > >
> > >
> > >
> > > _______________________________________________
> > > 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>
>
> > > 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>
> > 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/fb3c3f0f/attachment-0001.html>
More information about the Password-Store
mailing list