Group permissions not being honored
ArgentEnergy opened this issue · comments
On the latest version (v4.0.1), create a group (e.g. "contractors") with the below permissions.
reporting | Evidence | Can add Evidence
reporting | Evidence | Can change Evidence
reporting | Evidence | Can delete Evidence
reporting | Evidence | Can view Evidence
reporting | Report | Can add Report
reporting | Report | Can change Report
reporting | Report | Can view Report
reporting | Report finding | Can add Report finding
reporting | Report finding | Can change Report finding
reporting | Report finding | Can delete Report finding
reporting | Report finding | Can view Report finding
rolodex | Project POC | Can add Project POC
rolodex | Project POC | Can change Project POC
rolodex | Project POC | Can delete Project POC
rolodex | Project POC | Can view Project POC
Add a regular user to this group. Log in as the regular user. The Report Templates menu item and page are available even though the Report Template permissions aren't in the group. It's possible for this user to edit and delete unprotected report templates and upload their own.
I expected that this page and server-side functionality would not be accessible as the permissions weren't in the group.
This is not a serious issue as we lock our templates down to only allow admin users to modify them but does highlight a permission issue.
It looks like group permissions aren't being used. I'm assuming the users in those groups would only have those permissions. If a user is not assigned to a group then I figured they would have the permissions of the user role.
Using the same group (e.g. contractors), it was possible for a user to view projects they weren't assigned too. Visit the Project History for a client /rolodex/clients/1#project-history and then select a project they weren't assigned too or should see. I wasn't expecting them to see the client page as the permission to view a client wasn't there in the group.
Our goal is to have employees and contractors where employees would have the user role. We occasionally use contractors so the thought process was creating a group where a contractor can only see limited data they need for their test. Once the test is completed, we would deactivate their account and remove network access.
We're also running into an issue where users assigned to the user role can't view clients, projects unless assigned to them. I had to make everyone a manager for now but would be nice to have group permissions working so I can create an employee group and contractor group with a certain set of permissions.
Hey @ArgentEnergy, I am back after vacation and catching up. It looks like you figured this out, but to clarify:
Ghostwriter does not use Django's built-in group and permissions. They technically apply because they are built-in, but may create inconsistencies and unforeseen problems in the web GUI. The GraphQL API will not use them at all.
It's also intentional for a regular account with the user role to be unable to see anything until assigned to a project by someone with the manager role. You can invite an account to view a client or project without having to assign the account to a project. This isn't possible to do via the web GUI right now, but an admin can do it via the admin panel. There will be a way to do this as a manager or admin in the web GUI in a future release.
Your contractor scenario is similar to something I tested in the release candidates for v4.0. There was a restricted role that was similar to a user but more locked down. I had designed it around the idea of a contractor or other third-party needing access to Ghostwriter. I didn't receive any feedback on it and it felt confusing so I removed it from the final release. It's still something I want to explore though.
What subset of privileges would you want a contractor to have?
Hey @chrismaddalena hope you had a great vacation.
It would be nice if the application was permission-based using the groups as I don't want employees being able to add finding templates. I'm fine with them adding custom findings to their specific report and if it becomes a common finding then I would review and add it into the finding boilerplate in Ghostwriter.
This might be the best approach as I'm sure other people have different use cases on permissions and would offer the most flexibility. I was thinking if a user isn't assigned to a group then the role would take precedence.
We're trying to have it so only the lead of application security, network security, etc... would be responsible for the finding boilerplate. I think everything else is fine as I don't want to be responsible for creating clients and then assigning employees to projects and setting projects up.
For contractors as we don't use them often, I'm fine with creating clients and setting the projects up to assign them to it. I would want to give contractors the ability to edit their own projects they are assigned too, create a report, add/update/delete evidence in their report, and view finding boilerplate. I believe that would cover all aspects needed for a contractor to only see the limited data they are allowed to see and complete a test.
Thanks for the explanation. I'll look into how it might be possible to customize some of the roles more easily.
Some good news: You can restrict who can create, edit, or delete findings in the library. From the sidebar, go to the Administrative section and open User Mgmt. Click a user and find this section to make adjustments:
@chrismaddalena Unfortunately I have to make everyone a manager and that section (Permission Augmentation) mentions it only applies to the user role. Not a deal breaker as we have been using GW for a year now but hoping group functionality in the future will resolve all this.
@ArgentEnergy That's true. Those permissions affect the user role. If someone has the manager role they can create, edit, and update findings.
If everyone has the manager role, Ghostwriter v4 basically works just like v3 and earlier in regards to permissions and what everyone can do.
I'll close this issue for now, but I have added a backlog item for looking into allowing customization or adding a customizable role that would work for contractors or similar situations.