Your browser was unable to load all of the resources. They may
have been blocked by your firewall, proxy or browser configuration.
Press Ctrl+F5 or Ctrl+Shift+R to have your browser try again.
For point 1, we can get it implemented, please go ahead to file an improvment request at track.pmease.com
For point2, it is difficult to implement as QB allows scripting which means that user can modify the system via script to eventually get them the admin right if they can add steps to run.
Created:
http://track.pmease.com/browse/QB-2216
I suspect the problem with point 2 is that scripts are run as a user that has access to the API that allows modification of the user rights.
Using an analogy from Linux. If the user_access file was only writeable by the user quickbuild_super_admin and scripts were run by the user quickbuild_script_runner. Then any script that tried to write to the user_access file would fail with insufficient privileges.
In SQL the same could be achieved if only quickbuild_super_admin had write access to the UserAccess table.
Yes in theory that can be implemented that way, not to say this is an overkill for a system like QB, there are still security holes, for instance if the user add a step to call an external build script to alter QB files via external command, as all QB users are running under context of the same OS user. So as long as user is allowed to run script (or external commands), it is not possible to prevent the user from doing harmful things except to map each QB user to different OS user.
It may sound like overkill but in a corporate environment there are real concerns when QB is a business critical system.
I can appreciate the difficulty in modifying the underlying QB infrastructure to allow different actions to be executed with different privilege levels. However, please do not underestimate this aspect of your product especially when it is used in an environment where read / write access to almost every system is tightly controlled and enforced.
So this is the reason why we highly recommened not to allow non-admin users from edit configurations. As long as you allow them to edit configurations, the security holes exists even if we implement a system as you mentioned with " user_access" file, as all QB users are running as a single OS user, and you can not limit certain users from running external command to alter the system.
But why do you need to run user sessions and build jobs as the same OS user?
Certainly everyone that logs into QuickBuild should be operating as the same OS user, but why does the QuickBuild service that executes builds also use that OS account?
For example, I could write some malicious code and compile it as a Windows service. But Windows runs services as the LocalService account not Admin, so no matter how malicious my code may be it won't have any effect unless I can trick Windows into elevating the privileges of my service.
From a usability perspective, our QB installation is used by many developers, QA etc. across many different teams, as such restricting the ability to edit configurations to 2 or 3 admins is not ideal. Even if we remove Edit Settings permission from all users this will not close the hole. Any build job run on the server could execute code that modifies the QB installation, because build jobs are run as the same OS user that has write access to the QB files.
Running build jobs as a different OS user requires tight integration with OS (for instance to determine OS user relationsthip between build jobs) and this is too complicated for an application like QB, and this is a design choice that we will not follow that direction. As far as I know, there is no any CI software in the market doing such things. Almost all software out there only allows administrators to edit configuration.
One way to protect the QuickBuild serfver is to disallow running of steps on the server node. Instead, set up agents on other boxes. You can identify the user/password for the agent service, allowing the agent to run as whatever user you choose.
Of course, a malicious user could modify the configuration to allow steps to run on the server... perhaps you can put the server installation files on a read-only network share and access them from there. Or back up the files, and have a regularly running script (outside of QB) that monitors them... but a malicious user would just make script changes to disable it.
However, it sounds to me like you are looking for a technical solution to what is basically a personnel problem. Why are your users writing malicious code?
