| Index | SE061 |
|---|---|
| Title | ~ubuntu-security membership |
| Status | Approved |
| Authors | Alex Murray |
| Type | Informational |
| Created | 2023-11-01 |
Abstract
Permission to upload to the -security pocket within the Ubuntu archive is controlled by membership within the ~ubuntu-security Launchpad group, which defines the Ubuntu Security team. Membership within this group has traditionally been equivalent to membership of the ~canonical-security Launchpad group (which is used to designate Canonical employees who are members of the Ubuntu Security team). However, to align with the community expectations of the Ubuntu project, it is desirable to allow community members to be able to be present within the ~ubuntu-security group. This specification aims to capture the expectations from both ~canonical-security and community members as well as the process for how membership within the privileged ~ubuntu-security group is defined.
Rationale
Security updates for Ubuntu are managed by the ~ubuntu-security Launchpad team. Members within this team are granted permission to publish to the -security pocket within the Ubuntu archive for all of the stable Ubuntu releases. Packages published to the -security pocket are immediately published to security.ubuntu.com and then synced to the -updates pocket as well. Unlike updates for packages for bug fixes, there is no -proposed pocket or SRU process or similar to provide third-party review or help catch issues before they are published to the wider Ubuntu community. As such, membership within this group grants immense power within the Ubuntu distribution, and so needs to be carefully managed. ~ubuntu-security members also have the permission to modify various repositories and systems as required to perform their duties, such as tracking CVEs, publishing USNs etc. Finally, ~ubuntu-security members may also have access to embargoed information regarding various vulnerabilities - it is of paramount importance that these embargoes are respected by all members and so team members are trusted to keep such information private.
Traditionally, only Canonical employees within the Ubuntu Security Team have been granted access to this Launchpad team. This coupling of employment with membership of ~ubuntu-security, along with the various vetting processes that occur as part of gaining employment with Canonical, provide an innate degree of trust and assurance that members of ~ubuntu-security are unlikely to abuse their privileged access. The use of a standard on-boarding / mentoring process for new hires within the Canonical Ubuntu Security Team also helps ensure that all members of ~ubuntu-security both understand their responsibilities and have been educated on how best to protect themselves from any appropriate threats. Peer-review of the first few uploads for new members also helps ensure that a high level of quality is maintained and that the expectations around this are also clear.
However, Ubuntu is a community project with input from many diverse community members. As such, it is desirable to ensure that community members can also potentially be granted access to the ~ubuntu-security group if they wish to contribute security updates for Ubuntu. In this case, a standardised process is required that ensures all new and prospective members of the ~ubuntu-security team (whether they are Canonical employees or not) are aware of their responsibilities and have demonstrated they are able to produce high quality updates that minimise the chance of regressions for users.
Specification
Team membership
Prospective membership within the ~ubuntu-security team is conditional on existing membership within one of the following existing Launchpad teams:
If an individual loses access to one of these teams (whether by ceasing to be employed as a member of the Ubuntu Security Team by Canonical, or by losing membership within the ~ubuntu-core-dev team), their membership within ~ubuntu-security will also be removed. In the case that an individual was a member of both these teams and loses membership within only one, their membership within ~ubuntu-security should still be retained. Membership within ~ubuntu-security can be revoked at any time if an individual is suspected of abusing their privilege.
Verified identity
To ensure trust in the Ubuntu Security Community, all ~ubuntu-security members are required to verify their identity with Canonical to ensure compliance with various contractual obligations.
History of high-quality sponsored security updates
A candidate must also have a history of high-quality security updates that have been previously sponsored by existing members of ~ubuntu-security over the preceding months. In the case of ~canonical-security members, a minimum of 2 months is required, whilst for ~ubuntu-core-dev this is extended to 6 months. For community members, this should include associated Launchpad bug reports that demonstrate a good understanding of the required process involved when preparing a security update, along with detailed test results that demonstrate adequate testing and validation of the proposed update. For Canonical employees, these details are usually captured in internal communication channels instead but can also be detailed via Launchpad bugs as well.
Continued, on-going security updates
~ubuntu-security members who are not also members of ~canonical-security are required to publish at least one security update every 6 months otherwise their membership lapses.
Demonstrated understanding of required tools and systems
A candidate should also be familiar with the use of the Ubuntu CVE Tracker, in particular the internals of the associated git repository, including the use of CVE files and the various scripts to manage them. Ideally the candidate will also have demonstrated this via associated merge requests to assign various CVEs to themselves and update their status accordingly during the patching process.
Demonstrated responsive and respectful communication
When publishing security updates, the original author is required to be responsive to any subsequent bug reports regarding regressions or similar. As such, they should be able to demonstrate a history of responsive communication with existing ~ubuntu-security members, as well as an understanding of their individual responsibility to handle regressions arising from any updates which they publish. They should also have a demonstrated history of respectful communication with both ~ubuntu-security members and the wider Ubuntu community, and have signed the Ubuntu Code of Conduct.
Demonstrated understanding of the responsibility of ~ubuntu-security membership
Since all members of ~ubuntu-security can publish updates directly to all users of any stable Ubuntu release, it is imperative that prospective members have a thorough understanding of their responsibilities. Their Launchpad credentials are the sole arbiter of their permission to perform such uploads and thus members must take care to ensure these credentials are not compromised. Initial logins to Launchpad are managed by the login.ubuntu.com SSO service and all ~ubuntu-security members are required to use 2FA which reduces the risk of their credentials being compromised. In addition, all members should use a unique, randomly generated passphrase for login.ubuntu.com and store this within a suitable password manager. However, various tools that use the Launchpad API may then store their own credentials locally on disk. Therefore, all members should have their systems configured to use full disk encryption to prevent offline attacks.
Approval via a minimum of four existing ~ubuntu-security members
All prospective members of ~ubuntu-security are required to be approved by at least four existing members of the team. Ideally this should be conducted publicly via a new, dedicated thread within the Security topic of discourse.ubuntu.com. The prospective member should provide details that demonstrate the above requirements, including appropriate links to historical Launchpad bug reports, or similar. Existing members can then use this as an opportunity to clarify the provided information or seek additional information from the candidate before casting a vote. The timeframe for voting should be a minimum of 7 and a maximum of 14 days. In the case of any dissenting votes, additional affirmative votes will be required to ensure there is a balance of four affirmative votes in total with a minimum of 75% of votes in the affirmative.
Announcement of new members to the devel-permissions list
All newly approved members will be announced to the devel-permissions mailing list by the individual which adds them to the team in Launchpad. This announcement should also include the list of votes. The following template can be used for this purpose.
From: $NAME_OF_ANNOUNCER <$EMAIL_OF_ANNOUNCER>
To: [devel-permissions@lists.ubuntu.com](mailto:devel-permissions@lists.ubuntu.com)
Subject: $NAME_OF_NEW_MEMBER has been added to ~ubuntu-security
Cc: $NAME_OF_NEW_MEMBER <$EMAIL_OF_NEW_MEMBER>
Recently, the ~ubuntu-security team reviewed the application by $NAME_OF_NEW_MEMBER for membership within the team.
The following votes were cast:
$NAME_OF_VOTER_1 +1
$NAME_OF_VOTER_2 -1
$NAME_OF_VOTER_3 +1
$NAME_OF_VOTER_4 +1
$NAME_OF_VOTER_5 +1
$NAME_OF_VOTER_6 +1
$NAME_OF_VOTER_7 +1
$NAME_OF_VOTER_8 +1
The application was approved with a balance of $N_PLUS_1 affirmative votes making up $N_PLUS_1/$N*100% of the total votes cast.
Congratulations and welcome $NAME_OF_NEW_MEMBER, I have added you to the team, please exercise caution with your new rights.
Thanks,
$NAME_OF_ANNOUNCER
On-boarding via pairing
Once granted membership to ~ubuntu-security, a new member will be paired with an existing member to help guide them initially through the USN publication process. This existing member can then also serve as a first point of contact for additional clarification, however new members are encouraged to seek help from any existing members as required.