From b0c622da7c0a8bdabb33d63fd0c2d7c2b9df02ef Mon Sep 17 00:00:00 2001 From: Alex Legler Date: Thu, 2 Apr 2015 11:09:31 +0200 Subject: Initial version --- support/documentation/index.html | 68 ++++ support/index.html | 78 ++++ support/news-items/index.html | 49 +++ support/package-database.html | 7 + support/security/index.html | 133 +++++++ support/security/stay-informed.html | 85 +++++ .../security/vulnerability-treatment-policy.html | 421 +++++++++++++++++++++ 7 files changed, 841 insertions(+) create mode 100644 support/documentation/index.html create mode 100644 support/index.html create mode 100644 support/news-items/index.html create mode 100644 support/package-database.html create mode 100644 support/security/index.html create mode 100644 support/security/stay-informed.html create mode 100644 support/security/vulnerability-treatment-policy.html (limited to 'support') diff --git a/support/documentation/index.html b/support/documentation/index.html new file mode 100644 index 0000000..0d27929 --- /dev/null +++ b/support/documentation/index.html @@ -0,0 +1,68 @@ +--- +nav1: support +nav2: documentation +nav2-show: true + +title: 'Documentation' +--- +
+ Looking for the Gentoo Handbook? +
+ + Gentoo Handbook + +

+ Our most referred to piece of documentation is the Gentoo Handbook. + It describes the installation process of a new Gentoo system in detail. + Click the button on the right to directly start reading it. +

+
+ +

+ Most of our documentation is available on the Gentoo Wiki: +

+ +
+
+
+
+

Finding Documentation on the Gentoo Wiki

+
+
+ If you know what you are looking for, you can simply search for one or more keywords: +

+
+
+ + + + +
+
+ +
+ Or, browse the Wiki contents using these categories: +

+ +
+ Core System + Software + Hardware + Desktop + Server and Security + Project and Community +
+ + Did you know? + Our documentation team maintains a list of featured Wiki articles that are worth a read. +
+
+
+
+ +

Other Guides and Project Documentation

+ +

+ There are a few guides that have not made the jump to the Wiki just yet. + You can find them on the archived copy of our previous homepage. +

\ No newline at end of file diff --git a/support/index.html b/support/index.html new file mode 100644 index 0000000..e04f023 --- /dev/null +++ b/support/index.html @@ -0,0 +1,78 @@ +--- +nav1: support +nav1-show: true +nav1-weight: 20 + +title: 'Support' +--- +

+ Got a question? We've got you covered. +

+ +
+
+
+
+

Getting Help with your Gentoo System

+
+
+

+ Gentoo is a volunteer-driven distribution and so are our support options: + We have a great Gentoo community that tests and helps document many aspects of the Gentoo distribution. +

+

+ We advise you to seek answers to your support questions in the following support venues: +

+
+ Frequently Asked Questions + Gentoo Documentation + Gentoo IRC Channels + Gentoo Forums + Gentoo Mailing Lists +
+ + Many Gentoo developers frequently visit those community channels and try their best to contribute to the ongoing discussions and questions. +
+
+
+
+ +
+
+
+
+

Hardware Requirements

+
+
+ The hardware requirements for each architecture are placed in our Gentoo Handbook, + in the Choosing the right installation medium chapter for your respective architecture. +
+
+
+
+ +
+
+
+
+

Reporting Bugs

+
+
+

+ Found a bug? Please report it! +

+
+ Please make sure that the problem is not caused by a misconfiguration on your part. +
+ Our support venues help you ascertain whether your issue warrants a bug report. +
+ Prior to reporting your first bug, please take a look at our guide to creating beautiful bug reports. +

+ When you're ready to report the issue, head over to our Bugzilla, where you can file a bug after registering and logging in. +
+
+ Go to Bugzilla +
+
+
+
\ No newline at end of file diff --git a/support/news-items/index.html b/support/news-items/index.html new file mode 100644 index 0000000..396aec7 --- /dev/null +++ b/support/news-items/index.html @@ -0,0 +1,49 @@ +--- +title: 'Repository News Items' +navtitle: 'News Items' + +nav1: support + +nav2: news-items +nav2-show: true +--- +

+ Important news regarding packages available in Gentoo are published via news items. You can find them below. +

+ +
+ Which items affect me? +

+ This page lists all available news items, but sometimes items don't affect you because you don't have the relevant package installed, + or use a different architecture. +
+ The emerge command notifies you after each operation if there are news items affecting your configuration: +

+

+ 

+  * IMPORTANT: 2 news items need reading for repository 'gentoo'.
+  * Use eselect news to read news items.
+

+ Use eselect news read new to read the pending items and mark them as read. +
+ +

+ For more information on the "Critical News" publication system, please see GLEP 42. +

+ +

Published News Items

+ + + + + + + + {% for entry in site.data.newsitems %} + + + + + + {% endfor %} +
TitleAuthorDate
{{ entry.title | xml_escape }}{{ entry.author | xml_escape }}{{ entry.date | xml_escape }}
\ No newline at end of file diff --git a/support/package-database.html b/support/package-database.html new file mode 100644 index 0000000..db3e6c1 --- /dev/null +++ b/support/package-database.html @@ -0,0 +1,7 @@ +--- +title: 'Package Database' +nav1: support +nav2: package-database +nav2-show: true +redirect: http://packages.gentoo.org/ +--- \ No newline at end of file diff --git a/support/security/index.html b/support/security/index.html new file mode 100644 index 0000000..034fa22 --- /dev/null +++ b/support/security/index.html @@ -0,0 +1,133 @@ +--- +title: 'Gentoo Security' +navtitle: 'Security' +nav1: support +nav2: security +nav3: security-index +nav2-show: true +nav3-show: true +nav3-weight: 1 +body_class: nav-align-h2 + +layout: page-nav3 +--- + +

Security in Gentoo Linux

+ +

+ Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users machines is of utmost importance to us. + The Gentoo Linux Security Project + is tasked with providing timely information about security vulnerabilities in Gentoo Linux, along with patches to secure those vulnerabilities. + We work directly with vendors, end users and other OSS projects to ensure all security incidents are responded to quickly and professionally. +

+ +

+ You can find a document describing the policy the security team follows to treat the vulnerabilities found in the + Gentoo Linux distribution on the Vulnerability Treatment Policy page. +

+ +

Installing a secure Gentoo system

+

+ The Gentoo Security Handbook gives information and tips + for building a secure system and hardening existing systems. +

+ +

Keeping your Gentoo system secure

+

+ To stay up-to-date with the security fixes you should subscribe to receive GLSAs and apply GLSA instructions whenever you have an affected package installed. + Alternatively, syncing your portage tree and upgrading every package should also keep you up-to-date security-wise. +

+

+ You can use glsa-check tool (part of the gentoolkit package) to: +

+ + +

Gentoo Linux Security Announcements (GLSAs)

+ +

+ Gentoo Linux Security Announcements are notifications that we send out to the community to inform them of security vulnerabilities related to Gentoo Linux or the packages contained in our portage repository. +

+ +

Recent Advisories

+ +{% include frontpage/glsa %} + +

+ For a full list of all published GLSAs, please see our GLSA index page. +

+ +

How to receive GLSAs

+

+ GLSA announcements are sent to the gentoo-announce@gentoo.org mailing-list, and are published via RSS and Atom feeds. +

+ +

Security Team contact information

+

+ Gentoo Linux takes security vulnerability reports very seriously. + Please file new vulnerability reports on Gentoo Bugzilla + and assign them to the Gentoo Security product and Vulnerabilities component. + The Gentoo Linux Security Team will ensure all security-related bug reports are responded to in a timely fashion. +

+ +

+ If you find errors or omissions in published GLSAs, you should also file a bug in Gentoo Bugzilla in the Gentoo Security product, but with GLSA Errors component. +

+ +

+ Report Security Vulnerability + Report GLSA Error +

+ +

Confidential contacts

+

+ You have two options to submit non-public vulnerabilities to the Gentoo Linux Security Team. + You may submit a bug in Gentoo Bugzilla using the New-Expert action, or the Enter a new bug report (advanced) link, + and check the Gentoo Security checkbox in the Only users in all of the selected groups can view this bug section. + You may also contact directly using encrypted mail one of the following security contacts: +

+ + + + + + + + + + + + + + + + + + + +
NameResponsabilityEmailGPG keyID (click to retrieve public key)
Alex LeglerOperational co-managera3li@gentoo.org0x12EE3000
Tobias HeinleinOperational co-managerkeytoaster@gentoo.org0xDC33B0EE
+ +
+ Note: + You can see a full list of Gentoo developers, including their GPG key ID on our list of active developers. +
+ +

Resources

+ +

Security pages

+ + +

Links

+ \ No newline at end of file diff --git a/support/security/stay-informed.html b/support/security/stay-informed.html new file mode 100644 index 0000000..d600c2b --- /dev/null +++ b/support/security/stay-informed.html @@ -0,0 +1,85 @@ +--- +title: 'Stay informed' +navtitle: 'Stay informed' +nav1: support +nav2: security +nav3: security-inform +nav3-show: true +nav3-weight: 20 +layout: page-nav3 +--- + +
+
+ +
+
+

Check your system's status

+ +

Use glsa-check to check your system's security status.
+ To see all advisories that affect your system, run:

+ +

% glsa-check -t affected

+ +

+ If you don't have the utility installed, run emerge -va app-portage/gentoolkit.
+ For more information, review the documentation on our Wiki.

+
+
+ +
+ +
+
+ +
+
+

Subscribe via E-Mail

+ +

Our advisories are posted to the gentoo-announce mailing list.

+ +

You can subscribe by sending an emtpy e-mail to:

+ +

gentoo-announce+subscribe@lists.gentoo.org

+ +

A confirmation email will be sent. Reply to this email to complete the subscription.

+
+
+ +
+ +
+
+ +
+
+

Feeds

+ +

We offer RSS and Atom feeds that you can subscribe to using your news reader:

+ + +
+
+ +
+ +
+
+ +
+
+

Twitter

+ +

There were several unofficial Twitter feeds containing GLSAs.

+ +

None of them are currently up to date. Stay tuned.

+ + +
+
\ No newline at end of file diff --git a/support/security/vulnerability-treatment-policy.html b/support/security/vulnerability-treatment-policy.html new file mode 100644 index 0000000..d7427fb --- /dev/null +++ b/support/security/vulnerability-treatment-policy.html @@ -0,0 +1,421 @@ +--- +title: 'Gentoo Vulnerability Treatment Policy' +navtitle: 'Vulnerability Treatment Policy' +nav1: support +nav2: security +nav3: security-vtp +nav3-show: true +nav3-weight: 10 +layout: page-nav3 +body_class: nav-align-h2 +--- + +

Scope

+ +

Supported architectures

+

+ Gentoo Linux is offered on many different architectures. + Some of these architectures have more developers than others and, as such, are able to respond to new security vulnerabilities more quickly. + While the ultimate goal of the Gentoo Security project is to ensure that all architectures receive security fixes at the same time, + we must also balance that against releasing security fixes and GLSAs as quickly as possible so that the majority of our users are informed and protected. +

+ +

+ For this reason, the Security Team separates Gentoo architectures into two groups, supported and unsupported: +

+ +
+
Supported
+
these architectures must have a stable fix committed before the GLSA can be released
+
Unsupported
+
these architectures will be notified of new vulnerabilities (cc on relevant bugs), however, we will not wait for a stable fix on these arches before issuing the GLSA and closing the bug
+
+ +

+ Here is the list of currently supported architectures: alpha, amd64, hppa, pcc, ppc64, sparc, x86. +

+ +

+ All architectures are welcome and encouraged to become a supported architecture. + There are two straightforward criteria that need to be met in order to be officially supported by the Gentoo Security project: +

+ + + +

Kernels

+

+ Kernels are not covered by the GLSA release process. + Vulnerabilities must still be reported and will be fixed, but no GLSA will be issued when everything is solved. +

+ +

Non-stable packages

+

+ Sometimes a vulnerability is found in a package that is not part of the stable trees. + This is the case when the vulnerability is a security regression in a newer (~ARCH) ebuild, but the older (stable) packages are not affected, or when the package has never had any stable ebuilds in the tree. + In this case the vulnerability must still be reported and will be fixed, but no GLSA will be issued when everything is solved. +

+ +
+ Note: This policy might be changed when our tools support more complex upgrade paths and if a sufficient number of GLSA coordinators join the Security Team. +
+ +

Vulnerability Feed

+ +

Published vulnerabilities

+

+ Each vulnerability should initially be entered as a Bugzilla entry with product "Gentoo Security" and component "Vulnerabilities" (assigned to security@gentoo.org). + Major security lists should have official scouts assigned to them which should ensure that all vulnerabilities announced on these lists get a security Bugzilla entry. +

+ +

Confidential vulnerabilities

+

+ Confidential vulnerabilities (for example coming from developer's direct communication or restricted lists) must follow a specific procedure. + They should not appear as a public bugzilla entry, but only in security-restricted media like a private bugzilla section or the GLSAMaker tool. + They should get corrected using private communication channels between the GLSA coordinator and the package maintainer. +

+ +
+ Note: + Communication for confidential vulnerabilities should be properly encrypted. + They should be sent to specific Security Team members and encrypted with their GPG key. + The list of the Security Team members is available on the project page, + their key IDs can be looked up on the Gentoo Linux Developers List + and their keys can be retrieved from the subkeys.pgp.net keyserver. + The use of IRC and other unencrypted messaging methods is discouraged. +
+ +

Dispatch

+ +

Severity Level

+

+ In order to seed the appropriate reaction times and escalation procedures, we need to assign a severity level to each vulnerability. + This severity level must be based on how widespread the affected software is amongst Gentoo users and depth of the vulnerability. +

+ +

+You can use the following two tables to help you assign the severity level: +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
How widespread the package isConfigurations affectedSeverity Component
System packageDefault or specificA
Common package (supposed present on at least 1/20 Gentoo installs)DefaultA
SpecificB
Marginal software (supposed present on less than 1/20 Gentoo installs)DefaultB
SpecificB
Package that never had an affected version stableDefault or Specific~
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Evaluate the vulnerability typeSeverity ComponentCorresponding GLSA severity
Complete remote system compromise: remote execution of arbitrary code with root privileges0high
Remote active compromise: direct remote execution of arbitrary code with reduced or user rights on a server1high
Local privilege escalation: flaw allowing root compromise when you have local access1high
Remote passive compromise: remote execution of arbitrary code by enticing a user to visit a malicious server or using malicious data2normal
Global service compromise: Denial of Service, passwords, full database leaks, data loss (symlink attacks)3normal
Others: Cross-Site Scripting, information leak...4low
+ +

+ Here is the table of the resulting severity levels. + They should be set to the Bugzilla severity level of the same name: +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Severity levelCorresponding evaluationsTarget delayGLSA
BlockerA0, B01 dayyes
CriticalA1, C03 daysyes
MajorA2, B1, C15 daysyes
NormalA3, B2, C210 daysyes
MinorA4, B3, B4, C320 days?
TrivialC4, ~0, ~1, ~2, ~3, ~440 daysno
+ +
+ Note: The delay indicated in this table is what we want to be the maximum time between the release of a fix by the upstream package developer and the release of a stable ebuild and corresponding GLSA. +
+ +

Security Bug Wrangler role

+

+ Someone should assume the responsibility of security bug wrangler and do the following tasks as soon as a new vulnerability enters Bugzilla: +

+ + + +

+ During this phase it may be necessary to ask the reporter for details. + The bug remains with status UNCONFIRMED or CONFIRMED as long as necessary. + When (if) the bug passes these sanity tests, it should be marked as IN_PROGRESS and the bug wrangler should do the following: +

+ + + +
+ Warning: You should not change bug severity once it has been assigned. If you want to increase developer awareness that a bug needs care, use the Priority field instead. +
+ +

Timeframe and backup procedures

+

+ This dispatch has to be done quickly after bug creation in order to seed short delays for major vulnerabilities and to show appreciation to the bug reporter. + The target delay is 12 hours. + The security bug wrangler has to maintain a list of possible GLSA coordinators with availabilities and preferred areas of expertise. In order to ensure permanent dispatch, the security bug wrangler job should have appropriate back-ups. +

+ +

Bug correction and GLSA draft

+ +

GLSA Coordinator role

+

+ The GLSA coordinator has responsibility for the following tasks: +

+ + + +
+ Note: If the bug makes progress and the assigned GLSA coordinator does not react, the other members of the Security Team can help keeping the bug rolling by updating its status. +
+ +

Timeframe and escalation procedures

+

+ In order to meet the target delay for vulnerability resolution, a number of escalation procedures have been defined. These include: +

+ + + +

Good practices for security bugs

+

+ Security bugs differ from other bugs, in that an easy and simple upgrade path must be presented to users through the GLSA. Therefore package maintainers and GLSA coordinators should follow these good practices: +

+ + + +

GLSA Publication Process

+ +

Peer review

+

+ Once ready, a GLSA should be submitted to peer review. + At least two members of the Security Team must approve the draft GLSA. Once the draft passes the peer review process, it should be assigned an official GLSA number. +

+ +

GLSA release

+

+ Once the GLSA passes the peer review process (and after making sure the ebuild has made its way into the stable tree), the GLSA coordinator should commit the GLSA XML in the Gentoo CVS repository. + Once this is done, the GLSA will automatically appear on the official GLSA index page and RSS feed. +

+ +

GLSA publication

+

+ The GLSA text version must be published by the GLSA coordinator to the following media: +

+ + + + + + + + + + +
Gentoo Linux official announcement mailing-listgentoo-announce@lists.gentoo.org
Gentoo Linux announcement forumhttp://forums.gentoo.org/viewforum.php?f=16
+ +

+ There should be one single email sent, with the following rules: +

+ + + +
+ Notes:
+ Developer key IDs can be found on the Gentoo Linux Developer list. All the Security Team GPG keys are published on public key servers, including (but not limited to) subkeys.pgp.net.
+ + To minimize errors in the publication process, the forum publication step is handled by an automatic poster when it receives the announcement.
+ + Starting Feb 2, 2012, we have decied to no longer CC any third parties. + The gentoo-announce mailing list has little other traffic, so that they should be subscribed there. + General security mailing lists such as full-disclosure or bugtraq are not our target audience, and having various distributions send notices about the same issues is not of any use to most readers there, they too should be on gentoo-announce. +
+ +

+ When the GLSA has been published the corresponding bugzilla bug should be resolved as FIXED, with the GLSA number referenced in the comments section of the bug. + GLSAMaker 2 offers this option after releasing the advisory. +

+ +

GLSA Errata

+

+ Sometimes an error will slip through the peer-review process and an incorrect GLSA will be published to the world. Depending on the severity of the error(s), the following policy for erratum should be applied: +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
GLSA error typeErratum action
Typos: presentation, grammar or syntax errorsDo nothing
Error in title: title is about another package or does not describe the vulnerability correctlyAn erratum GLSA should be published, replacing the erroneous one
Error in description: the problem is not described correctlyThe GLSA XML should be corrected, no publication
Omission: GLSA is correct but incomplete, you also need to update another package to get protection from that vulnerabilityA separate GLSA should be issued on the other vulnerable package
Error in affected/unaffected versions number, but people using stable packages and applying GLSA instructions are protected anywayThe GLSA XML should be corrected, no publication
Error in affected/unaffected versions number, people applying GLSA instructions are not at all protectedAn erratum GLSA should be published, replacing the erroneous one
\ No newline at end of file -- cgit v1.2.3-65-gdbad