[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bits from the Security Team (for those that care about bits)


In the weekend 14-16 January 2011, the Debian Security Team convened in
Linux Hotel, Essen. We discussed many things, a lot of security work was done 
and of course the necessary socialising wasn't forgotten. We'd like to thank 
the Linux Hotel for again receiving us in such a great way!

What follows is a high level summary of things discussed and of general 
interest. Don't forget to read our call for volunteers at the end! ;-)

* Improvements to the team workflow

Lots of discussion was dedicated to various aspects of improving the team
workflow. An important conclusion is that each week one team member will
be a "front desk", ensuring that all incoming communications and issues
are properly tracked and followed up upon. Others can then concentrate
on the actual fixing of those issues.

The team has been making use of Debian's Request Tracker for a longer while
now, but we want to encourage maintainers contacting us about issues to file
them there directly.[1] We will update our documentation for that.

Since a couple of years we've been handing off security issues of minor or
theoretical impact but for which a fix would be desirable at some point, like
certain classes of denial-of-service attacks, off to stable point updates.
We're looking for a person that wants to coordinate this: monitor the Security
Tracker for issues classified as such by the Security Team, converse with
maintainers to get such updates done and coordinate with the stable release
managers on this. Since no upload privileges are involved you don't even
need to be a DD.

The DSA release process itself has been redesigned from the ground up,
in order to eliminate as much as possible of the current manual work that
needs to be done for each advisory. Also we evaluated which information we
do and do not want to publish for an advisory. This includes a new way to
generate the advisory information, which will also allow for better machine
parsable formats, automatic signing of build logs and many wishlist items
for the Security Tracker. This bit still requires significant implementation
work though. This we hope to implement in the next months. It will also
allow the implementation of more advanced exports, like the generation of
OVAL signatures.

* Hardening compiler flags

Debian is currently one of the few distributions that doesn't enable hardening
options in the compiler that protect packages against certain types of
vulnerability. There has been work on this for a longer time but it didn't
yet come to fruition. A Birds of a Feather-session will be organised at the
upcoming Debian Conference to get all involved people together and implement

* Longer security support for Debian stable

Current Debian releases are supported for a year after the next version has
been released; this tends to come down to around three years in recent times.
There has been some interest to have Debian stable security supported for
a longer period of time, say five years. We've explored what conditions such
support should fulfil, but more discussion needs to happen before it can
become a reality.

* "Beta testing" of security updates

A past Google Summer of Code project was targeted at providing non-embargoed
but still pending security updates already to a select group of "beta
testers" (e.g. test environments in corporate setups) to get early feedback
in case of breakage. Unfortunately this hasn't been realised until now, but
we're still pushing the idea.

* README.test

Although many packages include a test suite that is run after package build,
there are packages that do not have such a suite, or not one that can be
run as part of the build process. It was proposed to standardise on a
README.test file, analogous to README.source, describing to others than the
regular maintainer how the package's functionality can properly be tested.
This is something we would like to see discussed and implemented for the
Wheezy development cycle.

* Backports security support

Gerfried Fuchs was invited to the meeting to discuss the security support
of backports.debian.org. Gerfried is mostly the only one working on this.
Some backporters don't track the status of their backports regularly and
thus have outstanding security fixes. It is needed to raise awareness of
the status page in the Security Tracker for backporters:
Help with backports security support would be welcome.

* Issues in specific packages

We further discussed some specific problematic packages. One example is
ia32-libs, which is difficult because it includes 100+ other source
packages. This will be handled better for Squeeze: we'll have to ensure
it's as up to date as possible at time of release, and will keep
updating it in stable point updates to include newer package versions
from the security archive (or the stable release itself).

For some packages it's difficult for the Security Team to set
up a representative test environment, like hardware-specific VoIP
applications or complex web applications. We're exploring technical
possibilities to open up the security update process so that
maintainers of such packages are more deeply involved in releasing
security updates for these packages.

* Call for volunteers

This is where we need you! :-) If you've read this far, chances are that
you're probably interested in what we do. Why not join us? There are several 

- Become stable-point-update-candidates coordinator (see above). Coordinate
  less severe security updates with maintainers, stable release management
  and of course the rest of the security team.

- Help out with security for backports.debian.org. Mostly this involves
  backporting newer package versions that include security fixes. Contact
  Gerfried Fuchs if interested.

- Are you following bugtraq, oss-security and other security news? Want to
  become a member of the security team? A great way to start is to
  work on our Security Tracker. Most current members of the Security Team
  started this way into the team and you could be next.
  Classify incoming issues, ensure issues from mailing lists are properly
  filed and prepare updates for vulnerabilities that are already public.
  See our introduction on how to start:
  and join us on irc.debian.org #debian-security.

The full minutes of the meeting can be found via:

On behalf of the Security Team,

Thijs Kinkhorst

[1] http://wiki.debian.org/rt.debian.org#SecurityTeam

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: