[pass] Extending pass with user-defined hooks / add ons
Emil Lundberg
lundberg.emil at gmail.com
Sat Aug 1 23:03:29 CEST 2015
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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?
-----BEGIN PGP SIGNATURE-----
iQJFBAEBCAAvKBxFbWlsIEx1bmRiZXJnIDxsdW5kYmVyZy5lbWlsQGdtYWlsLmNv
bT4FAlW9M+8ACgkQHSBkP9nuM69rmw/+OaFkxoXvnWdj0vytUVBYn0sVSn/wJRJH
V/LO6AJdUv7YixtFUqiOQsBNZIhpSdqE9Jz6WQtBKJfJivfUJ+JrBuSPNqHXRmB/
WnyIjcpNRyRMouYMYK7BmdryZyN1WPDYSD2oFuE/Z588NK/IU+L9lIM8eRQdyy44
UwxM5hLZ+UPCNTWJtyZMDA4DIjEXdMgecL119Cb05Act/5JgV6+cr0Mq5mq+s3uM
CeB4fS0bxFm+wVH0hUnpToDJfMUnjyYp/g1hHazV5Jm80YhdlJulKtVIBs5hcC2u
LIsBpNEOjGdKaAbf2FitC8/6pBlHhREQCrTLn2qJ1Utax/wz8/DLpx+dRUQaPNB2
Eo/GliYG5MOUc+WUG4z0zRmTyIEqbr16yv/PDplZKKObJ7dY1rJ1ed/hCUm76Wiq
Xk+osaCvYygs1SuT/e9E2ve1RE++6b/Pj8y+9w2ZMDEGmdADmaNyd8hRR/2O1+z3
wRViJNCPIq3/K3fVA1yH/fOTXSLIZZbWjlILKGFYgV1wPYkcvLD6SF9fKs3cys5H
JyUxuGB3sWOGYgSCwNbFx7uLcb6gL+Vwkpwzf/YMLw0jyUvj43oP2D/Tbb+h9hA8
oswm5SnNurDXBeg38klIHbM0fVxV468pulH0E00vWHAUH/n9uae/+Z648JZOG3LJ
MVFCd+pa7Hk=
=7sNY
-----END PGP SIGNATURE-----
On Sat, 1 Aug 2015 22:39 Lenz Weber <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>> 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>
>
> > > 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>
> > >
> > >
> > >
> > > _______________________________________________
> > > Password-Store mailing list
> > > 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>
> > 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/9957a50b/attachment.html>
More information about the Password-Store
mailing list