Skip to content

Secret role restrictions not enforced via API #4146

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
anatole-tol opened this issue Feb 12, 2020 · 2 comments · Fixed by #4151
Closed

Secret role restrictions not enforced via API #4146

anatole-tol opened this issue Feb 12, 2020 · 2 comments · Fixed by #4151
Assignees
Labels
status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application

Comments

@anatole-tol
Copy link

anatole-tol commented Feb 12, 2020

Environment

  • Python version: 3.6.8
  • NetBox version: 2.7.4

(seen also in this comment #2869 (comment) 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

@jeremystretch jeremystretch added status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application labels Feb 12, 2020
@jeremystretch jeremystretch self-assigned this Feb 12, 2020
@jeremystretch jeremystretch changed the title Secret not visible for non admin users Secret roles not enforced via API Feb 12, 2020
@jeremystretch jeremystretch changed the title Secret roles not enforced via API Secret role restrictions not enforced via API Feb 12, 2020
@jeremystretch
Copy link
Member

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.

@anatole-tol
Copy link
Author

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!

jeremystretch added a commit that referenced this issue Feb 12, 2020
…ement

Fixes #4146: Fix SecretRole permissions enforcement
@lock lock bot locked as resolved and limited conversation to collaborators May 20, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants