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