From 0420855bd377bf6b2f510a6423aefd5af62f207a Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 19 Jul 2005 13:24:16 +0000 Subject: add my talk git-svn-id: svn+ssh://svn.debian.org/svn/secure-testing@1441 e39458fd-73e7-0310-bf30-c45bca0a0e42 --- doc/talks/debconf5/Makefile | 39 +++ doc/talks/debconf5/debian-swirl.png | Bin 0 -> 2776 bytes doc/talks/debconf5/notes | 104 +++++++ doc/talks/debconf5/testing-security.paper | 450 ++++++++++++++++++++++++++++++ doc/talks/debconf5/ts_debconf5.tex | 87 ++++++ 5 files changed, 680 insertions(+) create mode 100644 doc/talks/debconf5/Makefile create mode 100644 doc/talks/debconf5/debian-swirl.png create mode 100644 doc/talks/debconf5/notes create mode 100644 doc/talks/debconf5/testing-security.paper create mode 100644 doc/talks/debconf5/ts_debconf5.tex (limited to 'doc/talks') diff --git a/doc/talks/debconf5/Makefile b/doc/talks/debconf5/Makefile new file mode 100644 index 0000000000..07320e45c8 --- /dev/null +++ b/doc/talks/debconf5/Makefile @@ -0,0 +1,39 @@ +TEX = latex +DVIPS = dvips +PDFTEX = pdflatex + +.PHONY: clean +.SILENT: all dvi clean + + +SOURCES = $(shell ls | grep -e '\.tex') +SOURCE = ts_debconf5 + +all: pdf + +pdf: $(SOURCES:.tex=.pdf) + +dvi: $(SOURCES:.tex=.dvi) + +ps: buildps + +buildps: $(SOURCES:.dvi=.ps) + +.tex.dvi: + $(TEX) $(TEXARGS) $(SOURCE) + +.dvi.ps: + $(DVIPS) $(DVIPSARGS) $< + +ts_debconf5.pdf: ts_debconf5.tex + $(PDFTEX) $< + $(PDFTEX) $< + +.tex.pdf: + $(PDFTEX) $(PDFTEXARGS) $< + +clean: + rm -rf *.log *.nav *.out *.snm *.toc *.aux + +distclean: clean + rm -rf *.pdf *.dvi *.ps diff --git a/doc/talks/debconf5/debian-swirl.png b/doc/talks/debconf5/debian-swirl.png new file mode 100644 index 0000000000..500075c597 Binary files /dev/null and b/doc/talks/debconf5/debian-swirl.png differ diff --git a/doc/talks/debconf5/notes b/doc/talks/debconf5/notes new file mode 100644 index 0000000000..66b4dada55 --- /dev/null +++ b/doc/talks/debconf5/notes @@ -0,0 +1,104 @@ +5 intro +10 how it works +5 how to help +10 how well it works +?? next steps +15 questions/discussion +-- +45 minutes + +intro: + What is the testing distribution: + - Query audience: Who doesn't know how testing works. + - Automatically stabelised version of unstable. + - Dependency, testing delay and RC bug metrics used to + decide when to update packages. + - Unique amoung linux distributions. + - Unique challenges, including security. + + Why testing cannot be secured: + All of these are real challenges the team faces. + + - Query audience: raise hands if you use testing + (Don't worry, the camera isn't pointing at you -- noone + will know!) + + Using testing is still attractive: + - desktop users + - custom Debian distributions + + +how it works: + + Team: + - Formed last fall (5 years after testing) + - Open team of DDs and non-DDs + - Members participate because: + + - Hired by custom Debian distro that is based on testing. + (Skolelinux, Univention Corporate Server) + - University deploying sarge on a large scale + + (Above is 1/2 of team; which explains why it took + this long to start the team) + + which needs to keep track of security issues anyway. + - Want testing to be usable by our users and for faster + releases. + - Want to make unstable more secure. + - Like the transparency of the team. + - "It's fun" + - Team is designed to scale well and be easy to grow. + - Low barriers for entry to team. + - No team members currently have priviliged info (vendor-sec). + - And we don't care! Much. + + Data: + - [ Maybe do a quick demo of running through CAN list ] + - Track data from DSAs, CVE ids, debbugs, full-discolsure, bugtraq. + Mostly CVE. + - Not vendor-sec -- open team + - Use simple database to track holes + - Just keeping up with this data is a large portion of our work. + - And it's parallizable. + - And its very helpful if all debian changelogs mention CVE ids. + + Getting things fixed: + - Team members work on finding/writing patches and bug filing. + - Some (DD) members work on NMUs to unstable. + - In the future, we hope to do advisories and NMUs via + testing-security direct to testing. + +how to help: + + DDs: + + anyone: + - grab an unfixed bug from the page, fix it, file a bug + with a patch, NMU as necessary, communicate to the team the + fixed package version and bug number. + - join the team, help check CANs, develop policy, etc + - ideas/patches to improve the interface, website and translations + - adapt the changelog autochecker from ubuntu (the python script + that scans ubuntu changelogs and generates + http://people.ubuntu.com/~pitti/ubuntu-cve.html) + +how well it works: "Lies, damn lies, and .." + + - Stats arn't my thing. + - Too busy working to try to gather much data. + - Most time-to-fix comparisons are innately flawed in one way or + another. + - Show the tracking page and explain how to read. + - One comparison: + - Better comparisons would involve looking at kernel security holes + - Or putting up honeypots + +next steps + + - making DTSA announcements + - getting fix delay down to 4 days + - i386 support to start with + - autobuilders, etc.. + + diff --git a/doc/talks/debconf5/testing-security.paper b/doc/talks/debconf5/testing-security.paper new file mode 100644 index 0000000000..7f7403bdbf --- /dev/null +++ b/doc/talks/debconf5/testing-security.paper @@ -0,0 +1,450 @@ +# Securing the Testing Distribution # + +Joey Hess, DebConf5, Helsinki Finland + +---------------------------------------------------------------------------- + +## Introduction ## + +Debian's unique "testing" distribution is a potentially useful distribution +for both Debian end users and Custom Debian Distributions, who need a +reasonably up-to-date but not unstable version of Debian. One of the +distribution's main downfalls in attracting users has always been the lack +of security support. Over the past year, efforts have begun to change that. + +## The "testing" Distribution ## + +Debian's "testing" distribution is intended to be an automatically +stabilised version of Debian unstable, which is, in theory, kept free +of most of the release critical bugs that block a Debian release, while +still containing reasonably up-to-date software. Testing is intended to be +suitable as the basis for a stable Debian release at all times. + +Testing grew out of the difficulty of managing a release based on the +unstable distribution. Before the advent of testing, Debian releases began +by taking a snapshot of unstable, fixing any show-stopper bugs, testing it, +and eventually releasing the snapshot as stable. As Debian grew larger and +supported more architectures, this process did not scale well, freeze +periods became ever longer, and Debian releases more out of date and less +internally consistent. These problems led to the invention of the testing +distribution in 2000 by Anthony Towns. + +Updated packages reach testing under the control of a program (`britney`) +which ensures that several conditions are always met before a package in +testing can be updated to a newer version: + + * The new version cannot have more release critical bugs than the + version already in testing. + * The new package has to have aged and been tested for 10 days in + Debian's "unstable" distribution, to help ensure it has no serious bugs. + However, this delay can be reduced to 5 or even 2 days if packages have + an urgent reason to be updated. + * The new version of the package must have been built successfully on + all the architectures Debian plans to release. + * All the dependencies of the new version must be satisfied by packages + in testing. + +Handing most of the day-to-day management of a linux distribution over to a +program is a bold and unique idea among linux distributions, and making it +work has involved some unique challenges, many of them beyond the scope of +this discussion. On the whole, though, the resulting distribution has been +useful for its intended purpose of serving as a base for stable Debian +releases. + +But ever since it was introduced, testing has seemed an attractive +distribution for other purposes as well. It's seemed useful for those who +need newer software than stable, such as updated desktop software, but +cannot deal with the problems inherent in using unstable. One example is +installing Debian on hundreds of desktops at a company or school, another +is installing it on a single computer which one does not have much time to +maintain. A third example is a Custom Debian Distribution, such as +[Debian-Edu](http://skolelinux.org). + +While testing is used in all of these ways, a nasty little problem has kept +it from being widely used, limiting its users to a few with enough manpower +to do a lot of additional work, and a few who would rather not admit they're +using it. That problem is the difficulty in securing this distribution. + +## Problems With Securing Testing ## + +There are many problems that keep testing from being secure, and most have +their roots in the same conditions that are used to automatically control +the upgrading of packages in testing. Indeed, every one of those conditions +causes its own problems that can keep a security update in unstable from +reaching testing in an appropriately fast time span for testing to be safe +and secure. + + * Most security problems are release critical bugs, but if the package in + testing has additional release critical bugs besides the security fix, + these can hold a crucial security fix out of testing indefinitely. + + The only way to avoid this is by back-porting the security fixes to the + package version that is in testing, but besides often being difficult + and introducing new bugs, back-ports need an upload queue like + testing-proposed-updates or testing-security, and Debian has not kept + these queues functional between stable releases. + * The built-in delays in propagation of packages to testing keep any + security fix out of testing for at least a couple of days, and possibly + longer if it was not marked as being of high urgency. + + Release managers are able to reduce these delays, but some delay still + exists, and reducing the delay increases the risk of buggy packages + entering testing, which has to be weighed against the security problem + if testing is to meet its original purpose. + * If a package fails to auto-build on even one architecture, or if an + architecture's auto-builder is slow or backlogged, this will keep it + from reaching testing. + + Release managers are able to force in a package on the architectures + for which it's already built, but breaking the consistency of testing + like this can cause other problems and must be done with care. + * A new version of a package often has dependencies on other new + package versions, and anything that delays those packages from reaching + testing can delay a security fix. + + Unlike all the other problems listed above, no solution is known for + this problem. It can be ameliorated by avoiding overly tight library + dependencies, but not avoided. + * Testing is based on unstable which is always in a state of flux and for + which security is by no means guaranteed. + +All of these problems seem so insurmountable that for years no-one dared to +try to work on making testing more secure. Recently though a team has +formed that intended to do that, although the problems above remain as +constraints that must be constantly worked around. + +## The Testing Security Team ## + +The testing security team was formed in the fall of 2004. It is an open +team which currently has a combined membership of half a dozen Debian +developers and users. + +Team members spend between a few hours, up to a day or two of work time per +week on tracking and fixing security issues in testing. This is a fairly +large ongoing time commitment for a volunteer group, and in a survey of +some of the participants, they gave some reasons for working on the +security of testing that are not common in Debian, as well as some that +will be familiar to many Debian developers: + + * One member works for a organization which is deploying Debian sarge + on a large scale and needs to keep track of security issues anyway. + + * One member works for the Debian-Edu distribution, which is based on + Debian sarge, had to provide its own security support for its prior + release (Skolelinux) which was based on Debian woody, and needs to deal + with security holes in testing. + + * One member works on another derived distribution (Univention Corporate + Server), which is not based directly on sarge, and needs to keep track + of security issues and cherry-pick fixes from Debian, and finds tracking + and fixing security holes in testing a useful way to do this. + + * One member wants to work on Debian as a whole, not just on maintaining + some packages, and finds working on security interesting. + + * Several members are interested in helping sarge release. + + * Several members want testing to have security support since they + perceive it to be a useful alternative to stable for some Debian users. + + * Several members pointed out that the testing security team also makes + Debian unstable more secure. + + * Several members appreciate the openness and transparency of the testing + security team, in which everything is done in public mailing lists, bug + tracking systems, and code repositories; compared to the stable + security team which does many things in secret. + + * At least one member thinks that "it's fun". + +Half of the members of the team have day jobs that involve large scale +Debian deployments, or distributions derived from Debian, all based on +the testing distribution. This could explain why it took four years from +the introduction of testing to the formation of this team; it took nearly +that long for such uses of testing to become both necessary and +conceivable, and the pressure of trying to do these things with testing has +been a powerful motivator for many team members. If that is the case then +we can hope to see the team grow as others find themselves in similar +positions. + +The testing security team is designed to scale up well and be easy to grow. +All of the work is innately divisible; our database of potential security +issues allows members to claim issues to check, and fixing the issues also +parallelises nicely. Little communication is needed between team members; +indeed days go by with the only communication being automatic updates on +who has checked which issues and what holes have been fixed. + +The barriers for entry to the team are as low as possible; team members do +not need to be Debian developers, the team operates on public information +about security issues, so there are no confidentiality requirements. The +only significant requirement is that team members have the time and skills +to do the work. + +Indeed one of the goals of the talk which this paper accompanies is to find +someone new in the audience who can join the team. If you are interested or +wish to contact the team, our mailing list is +. + +## Tracking Vulnerabilities ## + +A large part of the day to day job of the testing security team is simply +keeping track of security issues as they are discovered and announced, +checking whether they affect testing, and tracking fixes as they make their +way from unstable to testing. Some of this has been automated, but a lot of +the work must still be done by hand, and this work occupies a large part of +the total time spent by the team on security. + +Different team members monitor different sources of data about new security +holes, including the [bugtraq](http://www.securityfocus.com/archive/1) and +[full-disclosure](http://lists.grok.org.uk/full-disclosure-charter.html) +mailing lists, the Debian bug tracking system, security advisories from +Debian stable, and security advisories from distributions related to +Debian (such as Ubuntu) and not related (such as Gentoo). + +Unlike Debian's stable security team, we do not have access to the +vendor-sec mailing list where unreleased security holes are disclosed for +coordinated release by many linux distributions. From time to time we may +be forwarded such information but then we have to keep it private until it +is released, so only one team member will typically know about it. Since +this makes it hard to work as a team, we prefer to work with disclosed +security issues. + +Keeping all of these sources of security holes straight and correlating +holes that are often mentioned in multiple places can be challenging. +Luckily this is not a problem that is unique to this security team, and +there is already a solution: The security community is standardising on the +[Common Vulnerabilities and Exposures](http://www.cve.mitre.org/) +dictionary. CVE is a global way to identify security issues that may affect +multiple distribution or operating systems. Each new security issue is +assigned a CVE ID, and these IDs are used to identify the issue in +advisories, bug reports, changelogs, and so on. + +A sample CVE ID is "CAN-2005-1263", which refers to a linux kernel core +dump privilege escalation. Dozens to hundreds of new CVE IDs are issued +each week for security holes in linux and many other operating systems and +other software, and we try to have all the new IDs checked within a day of +each update. + +This is one of the most parallelisable parts of the work of the testing +security team, and also often one of the most tedious, as the majority of +CVE entries are for software not in Debian, and some CVEs lack much useful +information or are unlikely to really be security holes, and we have to +check them manually, one at a time. Debian contains so many packages and +there are enough different ways to write the name of a price of software +that it can involve quite a bit of checking just to see if a given piece +of software is in the distribution. Also, many CVE items affect multiple +packages in Debian due to code duplication and static linking, which can +make checking much harder. + +Debian developers can do three things to make the testing security team's +CVE tracking easier. + +1. If a security hole does not yet have a CVE ID assigned, contact the + team or someone else and work to get one assigned. +2. Always list CVEs in the subjects of bug reports about security issues. +3. Always list CVEs in the changelog for security fixes. + +As of June 2005, the testing security team had checked 8600 unique CVEs, +of which 1054 affected Debian. This included retroactively checking all +CVEs issued since the release of Debian 3.0. + +## Fixing Vulnerabilities ## + +The other half of the job of the testing security team is to work with +developers to get vulnerabilities fixed. Once we have identified a new +security hole, we will ensure that there is a bug in the Debian BTS for it +and if the maintainer can use our help, will work to find a patch or new +upstream release that fixes the hole, and if necessary, team members who +are Debian developers will make a Non-Maintainer Upload to fix the problem +in unstable. + +Once a package is fixed in unstable, we can automatically track its +progress into testing, and will work with the release managers and others +to deal with any issues that might keep it out of testing. Some of the +techniques we use to deal with problems that might hold a package out of +testing include: + + * Uploading a back-ported security fix to the testing-proposed-updates + queue, if that queue is functional. + + * Fixing unrelated release critical but not security-related bugs that are + blocking the security fix from reaching testing. + + * Getting hints added to move a package into testing more quickly if it + was uploaded with too low an urgency. + + * Dealing with problems that cause failure to build from source on the + auto-builders, or bringing auto-builder problems to the attention of the + package maintainer and/or auto-builder administrators. + + * Getting hopelessly insecure packages removed from testing. + + * Making it easy for the release team to follow what issues are keeping + security fixes out of testing, so they can use the above and other + techniques. They often do a better job than the testing security team + at pushing the fixes into testing. + +One further step is needed in the vulnerability fixing process before most +people will consider testing to really be security supported; that is +uploading fixes immediately to a temporary repository (such as +security.debian.org), and posting advisories so users can know a fix is +available for a security hole. + +The testing security team hopes to do this, but is hampered by lack of +access to security.debian.org and lack of auto-builder support for testing. +We hope that these infrastuctural issues will be resolved after the release +of sarge. If not, we do plan to work around them and try to offer a +security repository and advisories anyway. We consider this very important +as without these last two pieces, most users will still consider testing to +be insecure and not security supported, and will not take into account all +the work we are already doing. + +## Results ## + +Anyone deciding whether to use testing and rely on the security support +provided by the testing security team, or to instead use stable, or even +unstable, would like to see a comparison of how long it takes to fix holes +in each of these versions of Debian. + +For example, we could examine all security holes for which Debian Security +Advisories (DSAs) have been issued for stable in the past year, and check +to see how much longer it took the holes to be fixed in testing. Or we +could examine all holes that have been known to affect testing and compare +how long it took to get the hole fixed in unstable with how long it took to +get the same fix into testing. + +But this kind of comparison of how well the fixing of security holes is +managed is often flawed. Some of the pitfalls include: + + * Security holes differ widely in their severity, ease of exploitation, + how many systems are vulnerable, etc. Simply counting security holes + is not a good metric, and rating security holes or selecting only + "important" holes to concentrate on can be subjective. + + This becomes very complex when security holes can be combined in + different ways to produce a working exploit, as is often the case with + remote code execution and local root exploit holes. + + * A single security hole can affect one package, or dozens of packages, + and these can be fixed at different times and need to be tracked + separately. However, a security hole that affects a dozen packages may + still impact fewer machines than a hole that affects a single package. + + * Not all security holes will affect all distributions, but this doesn't + necessarily mean that the distribution with less security holes is more + secure. Instead it can mean that fewer people are reporting holes in + its code-base, for whatever reason, or that the same holes exist in its + code-base, but are not obvious due to code reorganizations. Or fewer + holes might exist, but be more more serious. Or expectations of what + constitutes a security hole can vary. + + These problems often show up in comparisons of the security of Windows + and Linux, and of Linux and other Unix clones. + + * While the testing security team has comprehensive lists of all holes + we've identified to affect testing, and have checked every CVE ID + since 2002, no equivalent lists exist for stable, and our lists may be + incomplete for unstable. + + The list of stable DSAs is known to be an incomplete list of security + holes that affect stable, because the stable security team triages the + more important and/or easy to fix hole first, and may never find the time + or reason to fix all holes. + + So even getting a list of holes that affect the distributions to + compare is problematic, without repeating all the work that has been + done for testing, for the other distributions. + +The comparisons that follow should be read with the above caveats in mind. +The only foolproof way to compare the security of two systems is probably +to put honeypots installed with each up on the internet and watch what +happens to them.. + +### Comparing stable and testing ### + +A very rough comparison can be done with data the testing security team +gathers on a daily basis. Since the beginning of this year, we have tracked +whether security holes are already fixed in testing or not when a DSA is +issued for the holes. + +However, no good data exists for the date that each of these holes was +fixed in testing, so we cannot compare how much more quickly or slowly the +fixes occurred, only which distribution fixed it first. And all of the +caveats above apply; security holes in DSAs vary in severity; DSAs can +cover multiple packages or holes; multiple DSAs may be released for one +hole; and a list of DSAs is not a complete list of holes that were +discovered in this time period. + +Of 112 DSAs issued between January and May of 2005, 56 (exactly 50%) were +not fixed in testing before the DSA was released; 37 (33%) were fixed in +testing first, and 19 (17%) did not affect software in testing. + +### Comparing testing and unstable ### + +To track which holes are not fixed in unstable yet, and which holes have +been fixed in unstable but have not reached testing, we use an +[automatically updated list](http://newraff.debian.org/~joeyh/testing-security.html). + +This list includes a count of the numbers of each type of unfixed hole, and +comparing these numbers is a useful (if flawed) metric to see if there is +typically more delay associated with fixing a hole in unstable in the first +place, or with getting the fix accepted into testing. + +Unfortunately historical data is not available for these numbers, however +they have been roughly equal during most of this year, which suggests that +on average approximately half of the time to fix a hole is spent in getting +the hole fixed and into unstable, and half in getting the fix into testing. + +One interesting consequence of this is that it might be a better use of the +testing security teams's time to focus more effort on getting holes fixed +in unstable, since this is a more tractable problem than working on issues +that can block a fix from reaching testing, and since this would benefit +users of both distributions. However, it's probably too soon to tell, since +the release team was aggressively working on pushing fixes into testing +during this time period because of the impending release of sarge, and that +has likely skewed the numbers. + +### Further Comparisons ### + +Kernel security holes are a class of hole that is especially interesting, +because it can affect users of all versions of Debian, and because these +holes can be easily categorised into a few sets: + +* remote root exploits +* local root exploits +* remote code execution +* remote denial of service +* local denial of service + +Gathering the data and comparing the security history of testing with that +of stable during the first six months of 2005 would be a worthwhile +approach to better characterising the relative security of stable and +testing. + +Other comparisons would be useful, especially if they were based on better +data and perhaps performed by a statistician. Real-world data about how +Debian machines are exploited would be even more useful in determining the +relative value of the work done by Debian's stable and testing security +teams. + +## Conclusions ## + +The mantra that "testing is insecure" has become less true over the past +year thanks to the work of the testing security team, but much work still +remains before users can count on the security of testing. The team needs +to grow to the point that it can begin issuing formal advisories for +security holes in testing, so that users can begin to take these security +efforts seriously. + +This effort began on the sidelines as a not-quite-official Debian project, +with many contributors who are not Debian developers; it is already +becoming a more recognised part of Debian as users, developers and even +release managers realise its usefulness, and it can be hoped that this will +grow into a formal security support for testing on the same par as Debian's +security support for stable. + +--------------------------------------------------------------------------- + +Copyright 2005 by Joey Hess . + +Licensed under the GNU General Public License. diff --git a/doc/talks/debconf5/ts_debconf5.tex b/doc/talks/debconf5/ts_debconf5.tex new file mode 100644 index 0000000000..ed8e519be1 --- /dev/null +++ b/doc/talks/debconf5/ts_debconf5.tex @@ -0,0 +1,87 @@ +\documentclass{beamer} + + +\mode +{ +} + +\usepackage[english]{babel} + +\title[] % (optional, use only with long paper titles) +{Securing the testing distribution} + +\author[] % (optional, use only with lots of authors) +{Joey ~Hess} + +\date[] % (optional, should be abbreviation of conference name) +{DebConf5} + +\pgfdeclareimage[height=2cm]{debian-logo}{debian-swirl} +\logo{\pgfuseimage{debian-logo}} + +\begin{document} + +\begin{frame} + \titlepage +\end{frame} + +\begin{frame} + \frametitle{The Debian testing distribution: insecure by design} + \begin{itemize} + \item + dependency hell + \item + unrelated release critical bugs can block security fixes + \item + built in "testing" delays + \item + autobuilder lag + \item + based on unstable, which has no security team + \end{itemize} +\end{frame} + +\begin{frame} + \frametitle{How Debian developers can help} + \begin{itemize} + \item + include CVE ids in changeogs and bug reports + \item + get CVE ids asigned for security holes that lack ids + \item + don't hide security fixes + \item + respond quickly to security bugs (or be NMUed) + \item + communicate with the team + \end{itemize} +\end{frame} + +\begin{frame} + \frametitle{A rough comparison of stable and testing} + 112 DSAs issued between January and May 2005 + \begin{itemize} + \item + 56 (50\%) fixed in stable first + \item + 37 (33\%) fixed in testing first + \item + 19 (17\%) did not affect testing + \item + XXX (XX\%) affected stable with DSA + \item + XXX (XX\%) did not affect stable + \end{itemize} +\end{frame} + +\begin{frame} + \frametitle{Links} + \begin{itemize} + \item + Testing Security Team: http://secure-testing.alioth.debian.org/ + \item + Tracking page: http://newraff.debian.org/~joeyh/testing-security.html + \end{itemize} +\end{frame} + +\end{document} -- cgit v1.2.3