-----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 <[email protected]> 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 <[email protected] > <mailto:[email protected]> <[email protected]>> 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 <[email protected] > <mailto:[email protected]> <[email protected]> <mailto:[email protected]> > <[email protected]> <mailto:[email protected]> <[email protected]>> 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: [email protected] <mailto:[email protected]> > <[email protected]> <mailto:[email protected]> > <[email protected]> <mailto:[email protected]> > <[email protected]> > > > > > > > Mobil: +49 1575 7180927 > > > > Web: http://www.steffenvogel.de > > > > Jabber: [email protected] > <mailto:[email protected]> > <[email protected]> > <mailto:[email protected]> > <[email protected]> > <mailto:[email protected]> > <[email protected]> > > > > > > > > > > > > > > > > _______________________________________________ > > > > Password-Store mailing list > > > > [email protected] > <mailto:[email protected]> <[email protected]> > <mailto:[email protected]> <[email protected]> > <mailto:[email protected]> <[email protected]> > > > > > > > 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 > > > [email protected] > <mailto:[email protected]> <[email protected]> > <mailto:[email protected]> <[email protected]> > <mailto:[email protected]> <[email protected]> > > > > 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----- > > >
_______________________________________________ Password-Store mailing list [email protected] http://lists.zx2c4.com/mailman/listinfo/password-store
