<p dir="ltr">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256</p>
<p dir="ltr">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?
<br>
-----BEGIN PGP SIGNATURE-----</p>
<p dir="ltr">iQJFBAEBCAAvKBxFbWlsIEx1bmRiZXJnIDxsdW5kYmVyZy5lbWlsQGdtYWlsLmNv<br>
bT4FAlW9M+8ACgkQHSBkP9nuM69rmw/+OaFkxoXvnWdj0vytUVBYn0sVSn/wJRJH<br>
V/LO6AJdUv7YixtFUqiOQsBNZIhpSdqE9Jz6WQtBKJfJivfUJ+JrBuSPNqHXRmB/<br>
WnyIjcpNRyRMouYMYK7BmdryZyN1WPDYSD2oFuE/Z588NK/IU+L9lIM8eRQdyy44<br>
UwxM5hLZ+UPCNTWJtyZMDA4DIjEXdMgecL119Cb05Act/5JgV6+cr0Mq5mq+s3uM<br>
CeB4fS0bxFm+wVH0hUnpToDJfMUnjyYp/g1hHazV5Jm80YhdlJulKtVIBs5hcC2u<br>
LIsBpNEOjGdKaAbf2FitC8/6pBlHhREQCrTLn2qJ1Utax/wz8/DLpx+dRUQaPNB2<br>
Eo/GliYG5MOUc+WUG4z0zRmTyIEqbr16yv/PDplZKKObJ7dY1rJ1ed/hCUm76Wiq<br>
Xk+osaCvYygs1SuT/e9E2ve1RE++6b/Pj8y+9w2ZMDEGmdADmaNyd8hRR/2O1+z3<br>
wRViJNCPIq3/K3fVA1yH/fOTXSLIZZbWjlILKGFYgV1wPYkcvLD6SF9fKs3cys5H<br>
JyUxuGB3sWOGYgSCwNbFx7uLcb6gL+Vwkpwzf/YMLw0jyUvj43oP2D/Tbb+h9hA8<br>
oswm5SnNurDXBeg38klIHbM0fVxV468pulH0E00vWHAUH/n9uae/+Z648JZOG3LJ<br>
MVFCd+pa7Hk=<br>
=7sNY<br>
-----END PGP SIGNATURE-----<br>
</p>
<br><div class="gmail_quote"><div dir="ltr">On Sat, 1 Aug 2015 22:39 Lenz Weber <<a href="mailto:mail@lenzw.de">mail@lenzw.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
-----BEGIN PGP SIGNED MESSAGE----- <br>
Hash: SHA256 <br>
<br></div><div bgcolor="#FFFFFF" text="#000000">
My reasoning behind this is inspired by git:<br>
<br>
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.<br>
<br>
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.<br>
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.<br>
<br>
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.<br>
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".<br>
<br>
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.</div><div bgcolor="#FFFFFF" text="#000000"><br>
<br>
<br>
Am 01.08.2015 um 17:38 schrieb Emil Lundberg:<br>
</div><div bgcolor="#FFFFFF" text="#000000"><span style="white-space:pre-wrap">><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> /Emil<br>
><br>
><br></span></div><div bgcolor="#FFFFFF" text="#000000"><span style="white-space:pre-wrap">
> On Sat, 1 Aug 2015 16:58 Lenz Weber <<a href="mailto:mail@lenzw.de" target="_blank">mail@lenzw.de</a>
<a href="mailto:mail@lenzw.de" target="_blank"><mailto:mail@lenzw.de></a>> wrote:<br>
><br>
><br>
> -----BEGIN PGP SIGNED MESSAGE-----<br>
> Hash: SHA256<br>
> <br>
> 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.<br>
><br>
><br>
> Am 01.08.2015 um 12:42 schrieb Steffen Vogel:<br>
> > Hi,<br>
> ><br>
> >> What about a system similar to Git[1] where
subcommands are just<br>
> >> exectuables in your $PATH?<br>
> ><br>
> > Having a „pass-age“ sub-command somewhere in
$PATH:~/.password-store/.hooks/ ?<br>
> > Thats a nice idea :-) I like it.<br>
> ><br>
> >> This has some benefits over keeping commands in
your password store:<br>
> >><br>
> >> * pass doesn't have to care about special or
"blessed" directories<br>
> >> * Subcommands can be written in any language<br>
> >> * It's easy for third party packages to add new
commands<br>
> >><br>
> >> Plus if you want to keep your passwords and
custom commands together you<br>
> >> can add ~/.password-store/.hooks (or whatever it
may be) to your $PATH.<br>
> ><br>
> > Convinced :-) I’d like to keep the addons together
with my passwords.<br>
> > This way, I can sync my add ons using „pass git
pull“.<br>
> ><br>
> > I would say, that we should agree to a hidden subdir
in ~/.password-store which gets automatically added to $PATH by
pass.<br>
> ><br>
> > Some proposals (which one do you like?)<br>
> ><br>
> > ~/.password-store/.hooks/<br>
> > ~/.password-store/.addons/<br>
> > ~/.password-store/.plugins/<br>
> > ~/.password-store/.subcommands/<br>
> > ~/.password-store/.extensions/<br>
> ><br>
> > Kind Regards,<br>
> ><br>
> > Steffen<br>
> ><br>
> > PS: I will prepare a patch soon (tm).<br>
> ><br>
> > —<br>
> ><br>
> > Steffen Vogel<br>
> > Robensstraße 69<br>
> > 52070 Aachen<br>
> ><br></span></div><div bgcolor="#FFFFFF" text="#000000"><span style="white-space:pre-wrap">
> > Mail: <a href="mailto:post@steffenvogel.de" target="_blank">post@steffenvogel.de</a>
<a href="mailto:post@steffenvogel.de" target="_blank"><mailto:post@steffenvogel.de></a></span></div><div bgcolor="#FFFFFF" text="#000000"><span style="white-space:pre-wrap"><br>
> > Mobil: +49 1575 7180927<br>
> > Web: <a href="http://www.steffenvogel.de" target="_blank">http://www.steffenvogel.de</a><br></span></div><div bgcolor="#FFFFFF" text="#000000"><span style="white-space:pre-wrap">
> > Jabber: <a href="mailto:steffen.vogel@jabber.rwth-aachen.de" target="_blank">steffen.vogel@jabber.rwth-aachen.de</a>
<a href="mailto:steffen.vogel@jabber.rwth-aachen.de" target="_blank"><mailto:steffen.vogel@jabber.rwth-aachen.de></a><br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > Password-Store mailing list<br>
> > <a href="mailto:Password-Store@lists.zx2c4.com" target="_blank">Password-Store@lists.zx2c4.com</a>
<a href="mailto:Password-Store@lists.zx2c4.com" target="_blank"><mailto:Password-Store@lists.zx2c4.com></a></span></div><div bgcolor="#FFFFFF" text="#000000"><span style="white-space:pre-wrap"><br>
> >
<a href="http://lists.zx2c4.com/mailman/listinfo/password-store" target="_blank">http://lists.zx2c4.com/mailman/listinfo/password-store</a><br>
><br>
> -----BEGIN PGP SIGNATURE-----<br>
> Version: GnuPG v2<br>
> <br>
>
iQEcBAEBCAAGBQJVvN55AAoJED87gGHnFM0sVkEH/2rowojY7ipv95xCW4phzYNK<br>
>
f9Ab5RSlAUP8yLdiBWck+rJ788W1/v4gKFSitKytuOSgN/PVZRS7IN/Kaza2RdGv<br>
>
sX/stzL5jirvVfxga28u71xjk+DnQx8y+ImUOYiB3eGz6W59AZh0l9IOAfnlbFTo<br>
>
Nt/ZN/7XXYLJJdsQTDPO79oZFkNnTsK9q9FED8YGEpN7KyeE7g1bVeFATMdEfhze<br>
>
t39Xb6RTFPMwPudID1rQTmAsrPJ315ihgja/66UM3oW9eEXbXXAEIFZPbXp6+b3d<br>
>
fJU0f0KL8tAWpqMajh+1ztzWJBfeR60P4/QqT3X4lLBFacP4g7ON7i91e3Rx184=<br>
> =ddwE<br>
> -----END PGP SIGNATURE-----<br>
><br>
> _______________________________________________<br>
> Password-Store mailing list<br></span></div><div bgcolor="#FFFFFF" text="#000000"><span style="white-space:pre-wrap">
> <a href="mailto:Password-Store@lists.zx2c4.com" target="_blank">Password-Store@lists.zx2c4.com</a>
<a href="mailto:Password-Store@lists.zx2c4.com" target="_blank"><mailto:Password-Store@lists.zx2c4.com></a><br>
> <a href="http://lists.zx2c4.com/mailman/listinfo/password-store" target="_blank">http://lists.zx2c4.com/mailman/listinfo/password-store</a><br>
></span></div><div bgcolor="#FFFFFF" text="#000000"><br>
<br>
-----BEGIN PGP SIGNATURE-----
<br>
Version: GnuPG v2
<br>
<br></div><div bgcolor="#FFFFFF" text="#000000">
iQEcBAEBCAAGBQJVvS6WAAoJED87gGHnFM0sdj0H/0fEJ8a2a+Scy1KmttbkzYFb
<br>
f6EiRn8PSz/bhiA/i2OF602/GjBvmIQ/Jm5GUvp/Pe7AIXQbFdfZeGqBtUE5Ewr+
<br>
ntAlgSlDSIHf9VZwjozWJXFrfGsVHdo5AUtK1xQd1/az7eK2Q44bxKQj+9uT+x5S
<br>
qOiJlKgXhhY3BP1qx78pjrXE9zgG53PHrLB6+OwJVnoUKKRwU8uhXcCRP2lyiUDg
<br>
xc6QRVrr13h0w+irM5s1SpJNGFPMYcb8rYZ3glewmQVLb4DtrKNRw8rPv72ZCIwW
<br>
KpdPbirAdPbFMsDoAwdSbivSlr2kn4JxHyBtYQIEqeSkHNw+YhrdTH4+l7aR5ak=
<br>
=IzEe
<br>
-----END PGP SIGNATURE-----
<br>
<br>
</div>
</blockquote></div>