Group sharing security
Konstantin Ryabitsev
konstantin at linuxfoundation.org
Wed Jun 14 18:01:52 CEST 2017
Hello, all:
I'm evaluating pass for use within a team of systems administrators, and
it seems like a good fit -- thanks again, Jason. :)
I'm curious about the "different keys per subpath" feature, though -- it
seems that it would be easy to defeat unless the git repository itself
applies some kind of permission control over paths. Say, we have two
teams:
Sysadmins:
- Alice
- Bob
Developers:
- Cathy
- Dwayne
The pass hierarchy would be:
sysadmins/
.gpg-id = alice, bob
systems/
somepass
developers/
.gpg-id = cathy, dwayne
services/
somepass
shared/
.gpg-id = alice, bob, cathy, dwayne
services/
somepass
What's preventing Cathy from inserting her key into sysadmins/.gpg-id?
She won't get access to the secrets right away, but the next time a
password is added or changed by a sysadmin, it will be encrypted to her
key as well as to those of alice and bob.
I know there will be a git log of that change, but it's easy to hide it
as part of a larger operation that touches a lot of files (say, Eve
joins the development team and both developers/ and shared/ trees get
modified to recrypt her key -- so a change to sysadmins/.gpg-id goes
unnoticed). Also, if .gpg-id files list keygrips instead of email
addresses, spotting a rogue entry will be very difficult in large teams.
Apologies if this has already been discussed -- I've only gone back a
few months in the archives.
Best,
Konstantin Ryabitsev
Director, IT Infrastructure Security
The Linux Foundation
Montréal, Québec
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/password-store/attachments/20170614/e9ed1183/attachment.asc>
More information about the Password-Store
mailing list