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