I realized while doing some work on encrypted tags that, while we restrict which users are able to read encrypted tags, we do not restrict which users can write to them.
Depending on how you have built your automation around collins, this could have very bad consequences.
For example, if you automatically make server passwords match the password set in collins, using a configuration management tool that runs regularly like puppet or chef, an attacker that could not read the password could set it to a value they know, and then gain access or elevated permissions to your server.
This PR aims to fix this vulnerability by adding a canWriteEncryptedTags permission, that restricts which users are able to write encrypted tags.
It also renames canSeePasswords to canSeeEncryptedTags to better reflect what the permission does - you may have reasons to encrypt non-password attributes. It does this in a backwards compatible manner, so your existing permissions configs that use canSeePasswords should continue to function.
Nice, LGTM. This should include some messaging in future release notes about backwards compatibility (or lack thereof) and provide a clear upgrade path.
I realized while doing some work on encrypted tags that, while we restrict which users are able to read encrypted tags, we do not restrict which users can write to them.
Depending on how you have built your automation around collins, this could have very bad consequences.
For example, if you automatically make server passwords match the password set in collins, using a configuration management tool that runs regularly like puppet or chef, an attacker that could not read the password could set it to a value they know, and then gain access or elevated permissions to your server.
This PR aims to fix this vulnerability by adding a
canWriteEncryptedTags
permission, that restricts which users are able to write encrypted tags.It also renames
canSeePasswords
tocanSeeEncryptedTags
to better reflect what the permission does - you may have reasons to encrypt non-password attributes. It does this in a backwards compatible manner, so your existing permissions configs that usecanSeePasswords
should continue to function.@tumblr/collins RFR