View Issue Details

IDProjectCategoryView StatusLast Update
0023679mantisbtadministrationpublic2017-12-30 18:36
Reportercovfefe Assigned Toatrol  
PriorityimmediateSeveritymajorReproducibilityalways
Status closedResolutionfixed 
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.
Attached Files

Relationships

related to 0020772 closedvboctor Allow administrators to impersonate users 

Activities

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

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

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 03:06

atrol

Committer: vboctor


Details Diff
Don't allow to set impersonate_user_threshold in database

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