Skip to content

Improper access control while fetching packages for a given group and subgroups

Summary

  • For some APIs, we want to get the packages from a given group (including its subgroups)
  • On the other hand, inspecting the group policy we can see that the read_package is granted on a group if either:

The problem, is that in the finders fetching those packages don't get projects with a minimum permission level (check the scope definition)

As a result, this could lead to situations where read_package is granted in error.

As an example, take the following structure: group/subgroup/project. group and subgroup are public and project is private. The package p is in project.

-> A user with the guest access level to p, can still access to p if the finder starts from group. That's because, p is visible to the user even though the user has a guest access level but if we read the group_policy.rb file, the user should have access to it (the user needs at least the reporter access level which is higher than guest)

How to reproduce

  • Create a public group
  • Within it, create a private project
  • Push a maven package to that project (gl_pru is useful for that 😺 )
  • Create a user and a PAT
  • Invite this user to the project as guest
  • Check that with the user, the UI will not show you the packages at all.
  • Create a folder to pull the package
    • Create a settings.xml file with:
<settings>
  <servers>
    <server>
      <id>gitlab</id>
      <configuration>
        <httpHeaders>
          <property>
            <name>Private-Token</name>
            <value>THE_GUEST_USER_PAT_HERE</value>
          </property>
        </httpHeaders>
      </configuration>
    </server>
  </servers>
</settings>
  • In the console, try to pull the package:
mvn dependency:get -DremoteRepositories=gitlab::default::https://gitlab.example.com/api/v4/groups/GROUP_ID/-/packages/maven  -Dartifact=MAVEN_PKG_GROUP_ID:MAVEN_PKG_ARTIFACT_ID:MAVEN_PKG_VERSION -Dtransitive=false -Ddest=. -s settings.xml
  • The package is downloaded and is available in . 😢

What is the current bug behavior?

read_package is granted for the conditions above

What is the expected correct behavior?

read_package should be rejected for the conditions above

Possible fixes

Edited by David Fernandez