Netbox: Secret role restrictions not enforced via API

Created on 12 Feb 2020  路  2Comments  路  Source: netbox-community/netbox

Environment

  • Python version: 3.6.8
  • NetBox version: 2.7.4

(seen also in this comment https://github.com/netbox-community/netbox/issues/2869#issuecomment-584106870 on closed ticket )

Steps to Reproduce

  1. Create a non admin account with granted all secret* permission (in my case it's thru and AD account and group)
  2. Add public key to account
  3. Activate public key with an admin acount
  4. User try to see a secret (unlock button is stil grey even after log off log on)
  5. Go on one secret page (/secrets/secrets/$secret-id/)
  6. we've got warning message : "you do not have permission to view secret"
  7. clic on edit button
  8. unlock button is now green and works

Expected Behavior

step 4 : unlock button is green and permit to add private key to session then see password
step 6 : unlock button is green and permit to add private key to session then see password

Observed Behavior

step 4 : unlock button is stil grey and permission deny message when try to use it
step 6 : we've got warning message : "you do not have permission to view secret"

The fact that we can see secret in step 8 is also an issue as the permission should works exactly the same way in any view.

Best regards,
Al

accepted bug

Most helpful comment

The root issue here is that secret role assignment is not being enforced on API calls. When you create a secret, it must be assigned to a role. This role is assigned certain users and/or groups which have permission to decrypt the secrets belonging to it. Users which don't belong to the role should not be able to decrypt the secret.

Everything above is correct until step eight: The user should not be given the option to decrypt the secret, assuming he has not been assigned to the secret's role. Further, decryption via the API should fail, and it currently does not.

We'll need to take measures to ensure that

1) The UI displays the "unlock" button only if the user belongs to the secret's role, and
2) Secrets retrieved via the API are decrypted _only_ if the user belongs to the secret's role.

All 2 comments

The root issue here is that secret role assignment is not being enforced on API calls. When you create a secret, it must be assigned to a role. This role is assigned certain users and/or groups which have permission to decrypt the secrets belonging to it. Users which don't belong to the role should not be able to decrypt the secret.

Everything above is correct until step eight: The user should not be given the option to decrypt the secret, assuming he has not been assigned to the secret's role. Further, decryption via the API should fail, and it currently does not.

We'll need to take measures to ensure that

1) The UI displays the "unlock" button only if the user belongs to the secret's role, and
2) Secrets retrieved via the API are decrypted _only_ if the user belongs to the secret's role.

This answer is awesome.

It's permit me to find how to manage access to some passwords and not the other one. I was searching for it and just found how to : edit secret role, i did not find it previously.

Thanks!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

bellwood picture bellwood  路  4Comments

Grokzen picture Grokzen  路  3Comments

Ali-Yazdani picture Ali-Yazdani  路  3Comments

aarjbdea picture aarjbdea  路  3Comments

mrfroggg picture mrfroggg  路  3Comments