KBOX Roles & Permissions fundamentally flawed?
Forgive me if this has been discussed already, but I could not find any mention.
So it seems the whole roles and permissions system of the KBOX is fundamentally flawed. If your user role has write permissions to Roles, you can give yourself permissions that you don't already have yourself.
Our goal is to utilize Organizations so that independent teams have full control over their organization. Access to creating custom Ticket Rules under Help Desk > Configuration > Queues > Customize Ticket Rules has the potential to break the KBOX for all Organizations (there's an update query that can be modified by someone who doesn't know what they're doing), so locking Organization administrators out of the Configuration tab of the Help Desk seems like it would be good enough. Not so. You'll also need to lock them out from creating new Roles or they could just assign themselves a role that has permissions to modify Help Desk > Configuration.
As System admins, we don't want to be in the business of creating user accounts each time an Org. admin has a new hire or wants to grant an existing employee permission to use the KBOX. We want each Org to feel like they are using their own KBOX without actually giving them their own KBOX (which is out of the question).
The only alternative I can think of that would work for us is to prevent any Org admins from being able to write to Roles. But that means, as System admins, we'll need to create a reasonable subset of all permutations of possible roles when creating each new Organization. Otherwise we'll have to be in the business of creating new roles whenever an Org admin needs one. All of this would be moot if the KBOX just prevented users with write access to Roles from creating a new role that granted permissions which they didn't have to give in the first place. It seems like a major flaw in the design and seriously weakens the whole permission system in general.
Any thoughts? Workarounds?
So it seems the whole roles and permissions system of the KBOX is fundamentally flawed. If your user role has write permissions to Roles, you can give yourself permissions that you don't already have yourself.
Our goal is to utilize Organizations so that independent teams have full control over their organization. Access to creating custom Ticket Rules under Help Desk > Configuration > Queues > Customize Ticket Rules has the potential to break the KBOX for all Organizations (there's an update query that can be modified by someone who doesn't know what they're doing), so locking Organization administrators out of the Configuration tab of the Help Desk seems like it would be good enough. Not so. You'll also need to lock them out from creating new Roles or they could just assign themselves a role that has permissions to modify Help Desk > Configuration.
As System admins, we don't want to be in the business of creating user accounts each time an Org. admin has a new hire or wants to grant an existing employee permission to use the KBOX. We want each Org to feel like they are using their own KBOX without actually giving them their own KBOX (which is out of the question).
The only alternative I can think of that would work for us is to prevent any Org admins from being able to write to Roles. But that means, as System admins, we'll need to create a reasonable subset of all permutations of possible roles when creating each new Organization. Otherwise we'll have to be in the business of creating new roles whenever an Org admin needs one. All of this would be moot if the KBOX just prevented users with write access to Roles from creating a new role that granted permissions which they didn't have to give in the first place. It seems like a major flaw in the design and seriously weakens the whole permission system in general.
Any thoughts? Workarounds?
0 Comments
[ + ] Show comments
Answers (2)
Please log in to answer
Posted by:
stradric
13 years ago
Turns out it's not as bad as we thought. We can use Organizational roles to lock out even the Admin users from various elements of the KBOX. However, it doesn't address the issue that any users with Write permission to Roles can grant themselves permissions which they don't have to give.
Posted by:
cblake
13 years ago
Technically this would be a fundamental flaw with all security systems- if you have admin access you can grant yourself permissions to just about anything. Consider granting somone Domain Admin Rights then asking them not to poke around in the SQL server or Exchange farm- not really the most secure of systems, since one could simply grant themselves DBA rights or Exchange admin permissions, or whatever. I sympathize with the theory, but the root of it is- just be careful when granting rights. At least until someone comes up with a better system :)
I do agree that this could be improved, and I've mentioned it to engineering, but it's never a bad plan to submit change/enhancement requests to [email=support@kace.com]support@kace.com[/email] - that's how we improve. Thanks for pointing this out, it's certainly been noted before, but that shouldn't deter you from "adding your voice" to that change request.
I do agree that this could be improved, and I've mentioned it to engineering, but it's never a bad plan to submit change/enhancement requests to [email=support@kace.com]support@kace.com[/email] - that's how we improve. Thanks for pointing this out, it's certainly been noted before, but that shouldn't deter you from "adding your voice" to that change request.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.