Security
Headlines
HeadlinesLatestCVEs

Headline

CVE-2022-31032: Permissions model — Tuleap latest version documentation

Tuleap is a Free & Open Source Suite to improve management of software developments and collaboration. In versions prior to 13.9.99.58 authorizations are not properly verified when creating projects or trackers from projects marked as templates. Users can get access to information in those template projects because the permissions model is not properly enforced. Users are advised to upgrade. There are no known workarounds for this issue.

CVE
#git#perl#auth

Type of users

Before we go further into the user registration process it is worth reviewing the various types of Tuleap citizens. There are always 3 of them:

  • Registered Users: once you have created your own account (see below) you can use your login/password to authenticate with Tuleap. Registered users have access to all Tuleap projects including source code unless the project administrators decided otherwise. And since the system knows about you, it enables you to customize your view of the system through your Personal Page, monitor Forums, software release, receive support request follow-ups, site updates and many other useful things.

  • Project Members: users who are actively working on a Tuleap hosted project. To become a project member, you must first become a registered user and then ask a project administrator to include you in the project members. Most of the time project members are part of the project team but are not limited to software developers. They can be in charge of the support activity, the project documentation or the project management. Project members can be granted different rights by the Project Administrator according to their role in the team (see Project Management for more details).

  • Project Administrators: registered users who create a new Tuleap project are elected as the first Project Administrators. Project Administrators have full rights over their projects except project deletion - a very unusual operation - that can only be done by a Site Administrator. In the course of the project life, the initial project administrator can grant (or revoke) the status of project administrator to any project member.

In addition to those roles, depending of the platform configuration, there might be two extra roles:

  • Anonymous Users: when you first visit the Tuleap site you are typically an anonymous user. Anonymous users can browse the site but many of the resources cannot be used or accessed by an anonymous user.

  • Restricted Users: users who are project members, or even project administrators, but with restricted access rights: they cannot access pages from projects they are not a member of. This special role is only enabled on servers in heterogeneous environments where corporate users and external consultants share the same server.

Site configuration

The permission model of Tuleap is first defined by the platform configuration. This configuration is done by a site administrator in Admin > Configure anonymous and restricted access section.

Admin of site access

As a site admin you decide whether:

  • Anonymous users can access the platform (Anonymous)

  • All users must be logged in (Registered)

  • All users must be logged in and restricted users are enabled (Registered + Restricted)

Please note that, in Registered + Restricted mode, site admin can customize the name of the two meta-groups Authenticated users (corresponding to all users, Registered and Restricted) as well as Registered users.

The default list of groups is:

Registered + Restricted

  • Authenticated users

  • Registered users

  • Project members

  • Project admins

  • project’s groups

In most configurations, Registered + Restricted is used to separate Registered regular users that are employees of the company from Restricted users that are subcontractors. Hence an “Acme” company might want to rename the groups:

  • Authenticated users -> ACME employees & subco

  • Registered users -> ACME employees

Then the list of available groups would be:

Registered + Restricted

  • ACME employees & subco

  • ACME employees

  • Project members

  • Project admins

  • project’s groups

Project’s permissions

In addition to site configuration, project administrators can decide whether their projects are:

  • Public

  • Private

  • Public inc. Restricted (only if platform is Registered + Restricted)

  • Private without Restricted (only if platform is Registered + Restricted)

When the Private without Restricted mode is used, no restricted user can be added to the project.

Resources visibility

You can find bellow the complete matrix of Who can access What depending to the various configurations:

Site configuration

Anonymous

Registered

Registered + Restricted

Project configuration

Public

Private

Public

Private

Public incl. Restricted

Public

Private

Private without Restricted

Anonymous

YES

NO

N/A

N/A

N/A

N/A

N/A

N/A

Authenticated users

N/A

N/A

N/A

N/A

YES

NO

NO

NO

Registered users

YES

NO

YES

NO

YES

YES

NO

NO

Project members

YES

YES

YES

YES

YES

YES

YES

YES

Project admins

YES

YES

YES

YES

YES

YES

YES

YES

project’s group

member

YES

NO (need to be

project member)

YES

NO (need to be

project member)

YES

YES

NO (need to be

project member)

NO (need to be

project member)

Notes:

  • N/A means that this option is not possible according to the configuration.

  • Project admins

  • At the time being, Authenticated users group is only available for “git repositories” resource

Resource configuration

The following matrix describe the resource manager possibilities according to various configurations.

At the time being, this applies only to “git repositories”

Site configuration

Anonymous

Registered

Registered + Restricted

Project configuration

Public

Private

Public

Private

Public incl. Restricted

Public

Private

Private without Restricted

Available groups

  • Anonymous

  • Registered user

  • Project members

  • Project admins

  • project’s groups

  • Project members

  • Project admins

  • project’s groups

  • Registered user

  • Project members

  • Project admins

  • project’s groups

  • Project members

  • Project admins

  • project’s groups

  • Authenticated users

  • Registered user

  • Project members

  • Project admins

  • project’s groups

  • Registered user

  • Project members

  • Project admins

  • project’s groups

  • Project members

  • Project admins

  • project’s groups

  • Project members

  • Project admins

  • project’s groups

Legacy resource configuration and visibility

For all other resources, the resource manager always sees all groups:

  • Anonymous

  • Registered user

  • Project members

  • Project admins

  • project’s groups

However, permissions apply the very same way:

Site configuration

Anonymous

Registered

Registered + Restricted

Project configuration

Public

Private

Public

Private

Public incl. Restricted

Public

Private

Private without Restricted

Anonymous

YES

NO

NO

NO

NO

NO

NO

NO

Registered users

YES

NO

YES

NO

YES

YES

NO

NO

Project members

YES

YES

YES

YES

YES

YES

YES

YES

Project admins

YES

YES

YES

YES

YES

YES

YES

YES

project’s group

member

YES

NO (need to be

project member)

YES

NO (need to be

project member)

YES

YES

NO (need to be

project member)

NO (need to be

project member)

CVE: Latest News

CVE-2023-50976: Transactions API Authorization by oleiman · Pull Request #14969 · redpanda-data/redpanda
CVE-2023-6905
CVE-2023-6903
CVE-2023-6904
CVE-2023-3907