Add setting(s) to disable certain shell actions
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
A large Self-Managed Premium customer has reported the following:
Currently the Gitlab Shell actions allow someone with a valid SSH key to perform actions that bypass some of the expected system authorization processes. The ones most concerning to our security team are being able to generate new 2FA codes and generating personal access tokens, both of which bypass user account protections.
In the event that any user's SSH key is compromised this allows the attacker to recreate the user account's recovery codes without their knowledge. The new recovery codes then immediately allow the attacker to authenticate and log into the site enough times to easily be able to browse all groups and projects that the user has access to and find one or all to download. For customers that rely only on the built-in MFA who don't use another form of SSO (say if they use local or LDAP auth and not Azure AD with SSO, for example) this could be a big security issue.
In the event that a Gitlab administrator's SSH key is compromised, the ability to generate PATs with any scope allows immediate API access to change not only settings at the project level but also any system administrative setting for the entire instance with little to no audit trail that I'm aware of. This is the one that concerns us the most because this is a direct bypass of all forms of SSO (both the Gitlab MFA and any external provider such as Azure AD) and allows changing any administrative setting that the API exposes.
We'd like to request a configurable setting to be able to enable/disable the "extended" (non-Git) Shell actions either individually or globally to maintain security and auditing of Gitlab instances. SSH keys are usually expected to be limited to actual Git operations and not these other actions that allow administrative control. We were unaware this was even possible to do via SSH with Gitlab so there's probably lots of other customers that are in the dark on this potentially easy way to gain admin access even with MFA/SSO. Let me know if there's more info I can provide or other detail on how this was discovered and I can provide it.