View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0023679 | mantisbt | administration | public | 2017-11-28 12:14 | 2017-12-30 18:36 |
Reporter | covfefe | Assigned To | atrol | ||
Priority | immediate | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 2.0.0 | ||||
Target Version | 2.10.0 | Fixed in Version | 2.10.0 | ||
Summary | 0023679: Limit change of impersonation threshold to global config | ||||
Description | If this is not fixed in the versions beyond 2.0.0, please fix it immediately! I just found out that if I impersonate a user (let's call our user "Person X" for that sake) in our Mantis and commit My Suggestion: Instead of just having "Person X" indicated in the username column of the Issue History Because to me the "Impersonate User" feature is without that a severe security issue: A nasty admin who wants to smear Person X could now commit disastrous changes in Mantis | ||||
Steps To Reproduce | Login as a global Admin to your Mantis instance, | ||||
Additional Information | See attachment section for suggestions. | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
Keep in mind that a nasty database admin can do even more. |
|
There is a setting $g_impersonate_user_threshold that can be set to NOBODY to deactivate this functionalty. |
|
@atrol No, not at all. The nasty admin of course can revert this config option to the default, so this is no adequate preventive action in my opinion. And I am aware that a nasty database admin can do even more harm, but this is no reason why |
|
Do you think that it's ok if the admin (user with access level administrator) is not able to change the option, but the admin (user with write access to config_inc.php) can change the option? |
|
Hi atrol! I am not sure about this. |
|
Depends on the definition of "big deal".
I don't like especially that a database schema extension is needed for this quite special use case. Again: Do you think that it's ok if the admin (user with access level administrator) is not able to change the option, but the admin (user with write access to config_inc.php) can change the option? |
|
I think we should model our access into two high privilege personas:
I can see us limiting impersonation setting to "System Administrator", but once it is enabled for ADMINISTRATORS, we won't do any protections or bookkeeping to track what they have done. I can see value in doing some auditing for what a user has done in general, but that applies to all users and not just administrators. |
|