View Issue Details

IDProjectCategoryView StatusLast Update
0023679mantisbtadministrationpublic2017-12-13 00:34
ReportercovfefeAssigned Toatrol 
PriorityimmediateSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
Product Version2.0.0 
Target Version2.10.0Fixed in Version2.10.0 
Summary0023679: 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
changes as this user, that there is no indication (at least on the Mantis Web UI) if it was really Person X committing
the changes or if it was an Admin impersonating her/him.

My Suggestion: Instead of just having "Person X" indicated in the username column of the Issue History
it should indicate "Person X (impersonated by admin Person Y)" if Person Y impersonated
Person X when doing the changes. The same applies for the Notes, if admin Person Y impersonates
Person X and writes a note, the same indication should be made.

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
as an impersonated Person X and get away with it. Person X would then be compromised however
because she/him has no possibility to prove that it wasn't her/him committing these changes but the admin instead,
Person X has no means to prevent such changes by an admin.

Steps To Reproduce

Login as a global Admin to your Mantis instance,
go to "Manage"->"Users"->Click on a user->Click on the "Impersonate User" button-> Go to any ticket to which the impersonated user has modifcation rights->Do some changes on the ticket->Press "save"->Scroll to History table

Additional Information

See attachment section for suggestions.

TagsNo tags attached.

Relationships

related to 0020772 closedvboctor Allow administrators to impersonate users 

Activities

covfefe

covfefe

2017-11-28 12:14

reporter  

atrol

atrol

2017-11-28 12:25

developer   ~0058258

A nasty admin who wants to smear Person X could now commit disastrous changes in Mantis

Keep in mind that a nasty database admin can do even more.

atrol

atrol

2017-11-28 12:36

developer   ~0058259

There is a setting $g_impersonate_user_threshold that can be set to NOBODY to deactivate this functionalty.
Do you agree that your issue can be closed?

covfefe

covfefe

2017-11-28 12:46

reporter   ~0058260

@atrol
Referring to you last post: "There is a setting $g_impersonate_user_threshold that can be set to NOBODY to deactivate this functionalty.
Do you agree that your issue can be closed?"

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.
The "Impersonate User" feature is useful for tesing permissions, it is basically a good idea - it is just the lack of transparency if
changes were really done by a user or by an impersonating admin.

And I am aware that a nasty database admin can do even more harm, but this is no reason why
to keep this low hanging fruit for abuse open then.

atrol

atrol

2017-11-28 14:58

developer   ~0058261

The nasty admin of course can revert this config option

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?

covfefe

covfefe

2017-12-07 10:53

reporter   ~0058350

Hi atrol!
Referring to your last comment: "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 am not sure about this.
However is it such a big deal to indicate that the user was impersonated when committing a change like in my proposal above?

atrol

atrol

2017-12-07 17:20

developer   ~0058352

Last edited: 2017-12-08 02:03

View 2 revisions

is it such a big deal

Depends on the definition of "big deal".

  • database schema changes to add a impersonating_user_id column to some tables
  • manage two user ids in session
  • update impersonating_user_id at various places when entering or changing data
  • consider impersonating_user_id at various places when displaying data
  • add impersonating_user_id at various places to SOAP and REST API
  • add some language strings
  • update documentation

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?

vboctor

vboctor

2017-12-09 18:39

manager   ~0058370

Last edited: 2017-12-09 18:39

View 2 revisions

I think we should model our access into two high privilege personas:

  • System Administrator - This person has access to the hosting server, scripts, database, etc, There is no point try to protect against such person.
  • Application Administrator - This person has full access to MantisBT, they can't access the host, scripts, database, or change some settings set by the System Administrator, but they are trusted not to mess with the application data.

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.

atrol

atrol

2017-12-10 08:13

developer   ~0058374

PR https://github.com/mantisbt/mantisbt/pull/1251

Related Changesets

MantisBT: master aaf79518

2017-12-10 08:06:08

atrol


Committer: vboctor Details Diff
Don't allow to set impersonate_user_threshold in database

Fixes 0023679
mod - config_defaults_inc.php Diff File
mod - core/authentication_api.php Diff File

Issue History

Date Modified Username Field Change
2017-11-28 12:14 covfefe New Issue
2017-11-28 12:14 covfefe File Added: 01_Suggestion_for_indicating_changes_done_by_admins_which_impersonate_an_user.png
2017-11-28 12:14 covfefe File Added: 02_Suggestion_for_indicating_notes_posted_by_admins_which_impersonate_an_user.png
2017-11-28 12:25 atrol Note Added: 0058258
2017-11-28 12:32 atrol Relationship added related to 0020772
2017-11-28 12:36 atrol Status new => feedback
2017-11-28 12:36 atrol Note Added: 0058259
2017-11-28 12:46 covfefe Note Added: 0058260
2017-11-28 12:46 covfefe Status feedback => new
2017-11-28 14:58 atrol Status new => feedback
2017-11-28 14:58 atrol Note Added: 0058261
2017-12-07 10:53 covfefe Note Added: 0058350
2017-12-07 10:53 covfefe Status feedback => new
2017-12-07 17:20 atrol Status new => feedback
2017-12-07 17:20 atrol Note Added: 0058352
2017-12-08 02:03 atrol Note Edited: 0058352 View Revisions
2017-12-09 18:39 vboctor Note Added: 0058370
2017-12-09 18:39 vboctor Note Edited: 0058370 View Revisions
2017-12-10 08:13 atrol Note Added: 0058374
2017-12-10 15:25 atrol Assigned To => atrol
2017-12-10 15:25 atrol Status feedback => assigned
2017-12-10 15:25 atrol Additional Information Updated View Revisions
2017-12-12 02:33 vboctor Changeset attached => MantisBT master aaf79518
2017-12-12 02:33 atrol Status assigned => resolved
2017-12-12 02:33 atrol Resolution open => fixed
2017-12-12 02:33 atrol Fixed in Version => 2.9.1
2017-12-12 15:50 atrol Fixed in Version 2.9.1 => 2.10.0
2017-12-12 15:50 atrol Target Version => 2.10.0
2017-12-13 00:34 vboctor Summary "Impersonate User" feature can be abused => Limit change of impersonation threshold to global config