Re: Securing Debian HOWTO
On Mon, Nov 18, 2002 at 02:38:54PM +0100, Javier Fernández-Sanguino Peña wrote:
> On Fri, Nov 15, 2002 at 03:01:03PM -0500, Matt Zimmerman wrote:
> > - Link to the security team FAQ rather than copying it It is
> > counter-productive to fork the FAQ.
>
> IMHO the location of the FAQ is unfortunate. It should not be published as
> it is currently but under the DDP hierarchy.
Why? And why did you decide to fork it instead of just linking to it?
I disagree that it should be relocated; almost all other information
published by the security team is available from
<http://www.debian.org/security/>.
> > - Section 7.3.1, Developer's guide to security updates, should link to the
> > Debian Developer's Reference, which is the authoritative and up-to-date
> > source for the same information
>
> Will do. Feel free to submit a patch.
Two patches are attached, one for the security team FAQ and one for the
Debian Developer's Reference.
--
- mdz
Index: securing-debian-howto.sgml
===================================================================
RCS file: /cvs/debian-doc/ddp/manuals.sgml/securing-howto/securing-debian-howto.sgml,v
retrieving revision 1.80
diff -u -r1.80 securing-debian-howto.sgml
--- securing-debian-howto.sgml 18 Nov 2002 13:43:28 -0000 1.80
+++ securing-debian-howto.sgml 18 Nov 2002 14:58:26 -0000
@@ -8209,205 +8209,7 @@
<sect id="debian-sec-team-faq">Questions regarding the Debian security
team
-<!-- FIXME: update from web page -->
-
-<sect1>What is a Debian Security Advisory (DSA)?
-
-<p>It is information sent by the Debian Security Team (see below)
-regarding the discovery and fix for a security related vulnerability
-in a package available in Debian GNU/Linux. Signed DSAs are sent to
-public mailing lists (debian-security-announce) and posted on Debian's
-web site (both in the front page and in the <url
-id="http://www.debian.org/security/"; name="security area">).
-
-<p>DSAs include information on the affected package(s), the security
-flaw that was discovered and where to retrieve the updated packages
-(and their MD5 sums).
-
-<sect1>The signature on Debian advisories does not verify correctly!
-
-<p>This is most likely a problem on your end. The
-debian-security-announce list has a filter that only allows messages
-with a correct signature from one of the security team members to be
-posted.
-
-<p>Most likely some piece of mail software on your end slightly
-changes the message, thus breaking the signature. Make sure your
-software does not do any MIME encoding or decoding, or tab/space
-conversions. Known culprits are evolution, fetchmail (with the
-mimedecode option enabled) and formail (from procmail 3.14 only).
-
-<sect1>How are security incidents handled in Debian?
-
-<p>Once the Security Team receives a notification of an incident, one
-or more members review it and consider Debian/stable vulnerable or
-not. If our system is vulnerable, it is worked on a fix for the
-problem. The package maintainer is contacted as well, if he didn't
-contact the Security Team already. Finally, the fix is tested and new
-packages are prepared, which then are compiled on all stable
-architectures and uploaded afterward. After all this tasks are done a
-DSA is sent to the public mailing lists.
-
-<sect1>How much time will it take Debian to fix vulnerability XXXX?
-
-<p>The Debian security team works quickly to send advisories and
-produce fixed packages for the stable branch once a vulnerability is
-discovered. A report <url
-id="http://lists.debian.org/debian-security/2001/debian-security-200112/msg00257.html";
-name="published in the debian-security mailing list"> showed that in
-the year 2001, it took the Debian Security Team an average of 35 days
-to fix security-related vulnerabilities. However, over 50% of the
-vulnerabilities where fixed in a 10-day time frame, and over 15% of
-them where fixed the <em>same day</em> the advisory was released.
-
-<p>However, when asking this question people tend to forget that:
-
-<list>
-
-<item>DSAs are not sent until:
-
-<list>
-
-<item>packages are available for <em>all</em> architectures supported
-by Debian (which takes some time for packages that are part of the
-system core, especially considering the number of architectures
-supported in the stable release).
-
-<item>new packages are thoroughly tested in order to ensure that no
-new bugs are introduced
-
-</list>
-
-<item>Packages might be available before the DSA is sent (in the
-incoming queue or on the mirrors).
-
-<item>Debian is a volunteer-based project.
-
-<item>Debian is licensed with a "no guarantees" clause.
-
-</list>
-
-<p>If you want more in-depth analysis on the time it takes for the
-Security Team to work on vulnerabilities, you should consider that new
-DSAs (see <ref id="dsa">) published on the <url
-id="http://security.debian.org"; name="security website">, and the
-metadata used to generate them, include links to vulnerability
-databases. You could download the sources from the web server (from
-the <url id="http://cvs.debian.org"; name="CVS">) or use the HTML pages
-to determine the time that it takes for Debian to fix vulnerabilities
-and correlate this data with public databases.
-
-<sect1 id="sec-unstable">How is security handled for <tt>testing</tt>
-and <tt>unstable</tt>?
-
-<p>The short answer is: it's not. Testing and unstable are rapidly
-moving targets and the security team does not have the resources
-needed to properly support those branches. If you want to have a
-secure (and stable) server you are strongly encouraged to stay with
-stable.
-
-<p><em>However</em>, the unstable branch usually gets security fixes
-quite quickly, because those fixes are usually available upstream
-faster (other versions, like those in the stable branch, usually need
-to be back ported).
-
-<sect1 id="sec-older">I use an older version of Debian, is it
-supported by the Debian Security Team?
-
-<p>No. Unfortunately, the Debian Security Team cannot handle both the
-stable release (unofficially, also the unstable) and other older
-releases. However, you can expect security updates for a limited
-period of time (usually several months) immediately following the
-release of a new Debian distribution.
-
-<sect1>Why are there no official mirrors for security.debian.org?
-
-<p>The purpose of security.debian.org is to make security updates
-available as quickly and easily as possible. Mirrors would add extra
-complexity that is not needed and can cause frustration if they are
-not up to date.
-
-<sect1>I've seen DSA 100 and DSA 102, what happened to DSA 101?
-
-<p>Several vendors (mostly of GNU/Linux, but also of BSD derivatives)
-coordinate security advisories for some incidents and agree to a
-particular timeline so that all vendors are able to release an
-advisory at the same time. This was decided in order to not
-discriminate against some vendors that need more time to prepare
-patches.
-
-<p>In some cases, the Debian Security Team prepares advisories in
-advance, and holds the advisory number until the advisory can be
-released. Hence, the gaps in DSA numbers.
-
-<sect1>How can I reach the security team?
-
-<p>Security information can be sent to
-<url id="mailto:team@security.debian.org";
-name="team@security.debian.org"> which only the members of the
-read. If desired email can be encrypted with the Debian
-Security Contact key (key ID 0x363CCD95).
-
-<sect1>What difference is there between security@debian.org and
-debian-security@lists.debian.org?
-
-<p>When you send messages to security@debian.org, they are sent to the
-developers mailing list (debian-private). All Debian developers are
-subscribed to this list and posts are kept private (i.e. are not
-archived at the public website). The public mailing list,
-debian-security@lists.debian.org, is open to anyone that wants to <url
-id="http://www.debian.org/MailingLists/"; name="subscribe">, and there
-are searchable archives available
-<url id="http://lists.debian.org/search.html"; name="here">.
-
-<sect1>How can I contribute to the Debian security team?
-
-<p>
-<list>
-
-<item>By contributing to this document, fixing FIXMEs or providing new
-content. Documentation is important and reduces the overhead of
-answering common issues. Translation of this documentation into other
-languages is also of great help.
-
-<item>By packaging applications that are useful for checking or
-enhancing security in a Debian GNU/Linux system. If you are not a
-developer, file a <url name="WNPP bug"
-id="http://www.debian.org/devel/wnpp/";> and ask for software you think
-would be useful, but is not currently provided.
-
-<item>Audit applications in Debian or help solve security bugs and
-report issues to security@debian.org. Other projects' work like the
-<url name="Linux Kernel Security Audit Project"
-id="http://kernel-audit.sourceforge.net/";> or the <url name="Linux
-Security-Audit Project" id="http://www.lsap.org/";> increase the
-security of Debian GNU/Linux, since contributions will eventually help
-here, too.
-
-</list>
-
-<p>In all cases, please review each problem before reporting it to
-security@debian.org. If you are able to provide patches, that would
-speed up the process. Do not simply forward Bugtraq mails, since they
-are already received. Providing additional information, however, is
-always a good idea.
-
-<sect1>Who is the Security Team composed of?
-
-<p>The Debian Security Team currently consists of five members and two
-secretaries. The Security Team itself appoints people to join the
-team.
-
-<sect1>Does the Debian Security team check every new package in
-Debian?
-
-<p>No, the Debian security team does not check every new package and
-there is no automatic (lintian) check to detect malicious new
-packages, since those checks are rather impossible to detect
-automatically. Maintainers, however, are fully responsible for the
-packages they introduce into Debian, and all packages are first signed
-by an authorized developer(s). The developer is in charge of analyzing
-the security of all packages that they maintain.
+The Security Team maintains a <url id="http://www.debian.org/security/faq"; name="FAQ"> along with <url id="http://www.debian.org/security/"; name="security information">.
<appendix id="harden-step">The hardening process step by step
Index: securing-debian-howto.sgml
===================================================================
RCS file: /cvs/debian-doc/ddp/manuals.sgml/securing-howto/securing-debian-howto.sgml,v
retrieving revision 1.80
diff -u -r1.80 securing-debian-howto.sgml
--- securing-debian-howto.sgml 18 Nov 2002 13:43:28 -0000 1.80
+++ securing-debian-howto.sgml 18 Nov 2002 15:02:09 -0000
@@ -5527,150 +5527,9 @@
<sect1>Developer's guide to security updates
-<p>This mail was sent by Wichert Akkerman to the <url
-id="+http://lists.debian.org/debian-devel-announce/2002/debian-devel-announce-200206/msg00004.html";
-name="Debian-devel-announce mailing list"> in order to describe Debian
-developer's behaviour for handling security problems in their
-packages. It is published here both for the benefit of developers as
-well as for users to understand better how security is handled in Debian.
-<p>Please note that the uptodate reference for this information is
-the <url id="http://www.debian.org/doc/manuals/developers-reference/ch-pkgs.en.html#s-bug-security"; name="Debian Developer's Reference">, this section will be
-removed in the near future.
-
-<sect2>Coordinating with the security team
-
-<p>If a developer learns of a security problem, either in his package
-or someone else's he should always contact the security team (at
-team@security.debian.org). They keep track of outstanding security
-problems, can help maintainers with security problems or fix them
-themselves, are responsible for sending security advisories and
-maintaining security.debian.org.
-
-<p>Please note that security advisories are only done for release
-distributions, not for testing, unstable (see <ref id="sec-unstable">)
-or older distributions (see <ref id="sec-older">).
-
-<sect2>Learning of security problems
-
-<p>There are a few ways a developer can learn of a security problem:
-
-<list>
-<item>he notices it on a public forum (mailing list, website, etc.):
-<item>someone files a bugreport (the <em>Security</em> tag should be
-used, or added by the developer)
-<item>someone informs him via private email.
-</list>
-
-<p>In the first two cases the information is public and it is important
-to have a fix as soon as possible. In the last case however it might
-not be public information. In that case there are a few possible options
-for dealing with the problem:
-
-<list>
-
-<item>if it is a trivial problem (like insecure temporary files) there is no
- need to keep the problem a secret and a fix should be made and
- released.
-
-<item>if the problem is severe (remote exploitable, possibility to gain root
- privileges) it is preferable to share the information with other
- vendors and coordinate a release. The security team keeps contacts
- with the various organizations and individuals and can take care of
- that.
-
-</list>
-
-<p>In all cases if the person who reports the problem asks to not
-disclose the information that should be respected, with the obvious
-exception of informing the security team (the developer should make
-sure he tells the security team that the information can not be
-disclosed).
-
-<p>Please note that if secrecy is needed the developer can also not
-upload a fix to unstable (or anywhere else), since the changelog
-information for unstable is public information.
-
-<p>There are two reasons for releasing information even though secrecy
-is requested/required: the problem has been known for too long, or
-the information becomes public.
-
-<sect2>Building a package
-
-<p>The most important guideline when making a new package that fixes a
-security problem is to make as few changes as possible. People are
-relying on the exact behaviour of a release once it is made, so any
-change made to it can possibly break someone's system. This is
-especially true of libraries: the developer must make sure he never
-changes the API or ABI, no matter how small the change.
-
-<p>This means that moving to a new upstream version is not a good solution,
-instead the relevant changes should be backported. Generally upstream
-maintainers are willing to help if needed, if not the Debian security
-team might be able to help.
-
-<p>In some cases it is not possible to backport a security fix, for
-example when large amounts of sourcecode need to be modified or
-rewritten. If that happens it might be necessary to move to a new
-upstream version, but it should always be coordinated with the security team
-beforehand.
-
-<p>Related to this is another import aspect: developers must always
-test your change. If their is an exploit the developer should try if
-it indeed succeeds on the unpatched package and fails on the fixed
-package. The developer should try normal usage as well, sometimes a
-security fix can break normal use subtly.
-
-<p>Finally a few technical things for developers to keep in mind:
-
-<list>
-<item>Make sure you target the right distribution in your debian/changelog.
- For stable this is stable-security and for testing this is
- testing-security. Do not target <codename>-proposed-updates.
-
-<item>Make sure the version number is proper. It has to be higher than the
- current package, but lower than package versions in later
- distributions. For testing this means there has to be a higher version
- in unstable. If there is none yet (testing and unstable have the same
- version for example) upload a new version to unstable first.
-
-<item>Do not make source-only uploads if your package has any binary-all
- packages. The buildd infrastructure will not build those.
-
-<item>Make sure when compiling a package you compile on a clean system
- which only has package installed from the distribution you are
- building for. If you do not have such a system yourself yourself you
- can try a debian.org machine (see http://db.debian.org/machines.cgi
- or set up a chroot (the <package>pbuilder</package> and
- <package>debootstrap</package> packages can be helpful in that
- case).)
-
-</list>
-
-<sect2>Uploading security fixes
-
-<p>After the developer has created and tested the new package it needs to be
-uploaded so it can be installed in the archives. For security uploads
-the place to upload to is
-ftp://security.debian.org/pub/SecurityUploadQueue/ .
-
-<p>Once an upload to the security queue has been accepted the package will
-automatically be rebuilt for all architectures and stored for
-verification by the security team.
-
-<p>Uploads waiting for acceptance or verification are only accessible by
-the security team. This is necessary since there might be fixes for
-security problems that can not be disclosed yet.
-
-<p>If a member of the security team accepts a package it will be installed
-on security.debian.org as well as the proper <codename>-proposed-updates
-in ftp-master or non-US archive.
-
-<sect2>The security advisory
-
-<p>Security advisories are written and posted by the security team. However
-they certainly do not mind if a maintainer can supply (part of) the text
-for them. Information that should be in an advisory is described in
-<ref id="dsa">.
+Information and instructions for handling security updates within
+Debian can be found in the <url
+ id="http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-bug-security";> name="Debian Developer's Reference">
<sect id="deb-pack-sign">Package signing in Debian
Reply to: