Javier Fernández-Sanguino Peña
2006-Mar-13 12:28 UTC
[Secure-testing-team] Oldenburg 2nd meeting summary
On Sat, Sep 24, 2005 at 07:11:25AM -0400, Micah Anderson wrote:> What follows are notes of the second testing-security meeting held at > Oldenburg September 23, 2005 with joeyh, micah, jmm, lamont, aba and > christoph in attendance:(..)> > . Publishing the testing-security''s severity levels > We discussed the severity levels that we use in our tracking, > and Micah agreed to dig out the discussions from the mailing list and > compile them all together so we can agree on them and make them documented. > low - not bad XSS issues > medium - things that are local security > high - remote holes/DoS (would rather terminate the service > rather than run a insecure version)I rather we had this homogeneous between teams and, moreover, was rather detailed so that people can have expectations on what will be fixed first. I mentioned CVSS previously, but this (good) references might come in handy: - Red Hat''s Security Classification: http://www.redhat.com/f/pdf/rhel4/SecurityClassification.pdf - Gentoo Linux Vulnerability Treatment Policy http://www.gentoo.org/security/en/vulnerability-policy.xml The Red Hat paper (which is certainly worth reading) has references to a number of other classifications. One thing I''ve been asking to the security team for some time is to add these ratings in their DSAs so that people can priorise the investigation of those based on that rating if they don''t have a metric of their own. I hope the security testing team does with DTSAs also. Regards Javier -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20050924/f4634f91/attachment.pgp
Javier Fern?ndez-Sanguino Pe?a wrote:> On Sat, Sep 24, 2005 at 07:11:25AM -0400, Micah Anderson wrote: > >>What follows are notes of the second testing-security meeting held at >>Oldenburg September 23, 2005 with joeyh, micah, jmm, lamont, aba and >>christoph in attendance: > > (..) > >>. Publishing the testing-security''s severity levels >> We discussed the severity levels that we use in our tracking, >> and Micah agreed to dig out the discussions from the mailing list and >> compile them all together so we can agree on them and make them documented. >> low - not bad XSS issues >> medium - things that are local security >> high - remote holes/DoS (would rather terminate the service >> rather than run a insecure version) > > > I rather we had this homogeneous between teams and, moreover, was rather > detailed so that people can have expectations on what will be fixed first. > I mentioned CVSS previously, but this (good) references might come in handy:Yes, these notes were not very clear about this. Basically we discussed coming to agreement about severity levels that we use in our tracking. There was some discussion on the list about different classifications, and I said I would dig up these and try and synthesize them and bring a summary to the list. We could then discuss this and agree on it. The notes then go on to give a very brief overview of some of the level discussions that we talked about at the meeting -- these were not meant to be the levels that we agreed on, I was just summing up the discussion. Micah
What follows are notes of the second testing-security meeting held at Oldenburg September 23, 2005 with joeyh, micah, jmm, lamont, aba and christoph in attendance: . Solidifying DTSA criteria We had some discussions about solidifying DTSA criteria. Some questions that we came up with helped us determine some more solid criteria: 1. Do we want to do DTSAs for packages not in testing because of missing arch builds? The current situation is that as soon as you tell it to start syncing the package as the builds for the architectures trickle in, they are then made available in the archive. This means that many architectures sync into the archives after the DTSA is published. This could result in announcing a DTSA, only to find a FTBS on an architecture. So far this hasn''t happened, as the buildd problems have only been chroot problems. One solution discussed was asking if RMs could push into testing even if a particular arch wasn''t built. However it was determined that if an arch was keeping up, but there wasn''t a build for a particular package, then there is something wrong and the RMs aren''t going to want to push it in. Criteria: we wait for the big three builds (i386, powerpc and amd64) before doing anything, don''t hold up an advisory because a slow arch (such as m68k) is held up 2. Automatically pulling things from the debian archive to t-s archive Automatically pull things from the debian archive to the testing-security archive. For example, sendmail has a bug but arm and m68k has not been built, the solution would be to automatically pull in the missing architectures from the main archive. This makes it easier to do a DTSA because you don''t need to wait for building to finish, when the missing architectures get built in the main debian they are automatically sync''d in. There are some restrictions to this: it can only be done after the dinstall happens. After a set number of days (10), the package would be automatically removed from testing-security. This would only be a solution for slow arch builds, not dependency issues. There would have to be dependency checking happening in this automatic procedure. Procedure would be to issue a DTSA and make a hint to pull this in from the debian archive Question: should we try to build the missing architectures in secure-testing? No, should be suppressed so that the normal debian autobuilder network can build those and get automatically sync''d over as the hints file will still exist Criteria: Aba will work on setting up this automatic sync procedure, we auto-sync from the debian archive when it is easy 3. Dependency problems: Some packages it would take at least 2 more months before the regular kdelibs would propogate because it is waiting for so many things, in this case it would make sense to define criteria and isolated security fixes have been published. Adjust the build-depends if its possible with the old tool-chain, then build and test heavily before uploading. Criteria: Backport packages by modifying build-depends where there are obscure dependency toolchain problems blocking, test heavily 4. If a non-free leaf package is not being built on an arch, then we need to coordinate with RMs; if it is a non-leaf package then it should be checked and autobuilt by aba (non-leaf = if it will remove a lot of other packages) . Statistics of downloads? Question: are there any statistics on who has downloaded what arches? Answer: not really, as some people sync via rsync to other hosts, so we don''t have reliable statistics . Refining DTSA steps We discussed some ways to refine some of the DTSA steps, as there are some issues and some of the steps do not need to be done manually. 1. Maybe the website generated from our database, rather than manual/static updates in the steps 2. If you run the DTSA script twice, it will make two entries in the list, unreleased tag in the DTSA list is that necessary 3. Updating DTSAs needs to be fixed so that the minor version number isn''t increased when wanting to regenerate existing DTSAs. Need a way to regerate an existing DTSA without increasing the minor number . DTSAs for kernel security problems Because there is a special procedure necessary to apply the security fixes for kernels (ie. reboot) it may make sense to do a DTSA for all kernel updates with security fixes. This would mean that we would only write DTSAs, and not build/upload any packages. The idea was floated to make a daily run script that gives a list of packages which have been installed in the archive and compare it against a list of known security holes, this would be for watching things like kernel entering testing . Long-running processes If you are dealing with a DTSA for a library that is being replaced by a newer version, existing applications that have this library still open need to be restarted; this is true of all long running processes. There is a script included in nagios that does some sort of lsof to tell you what applications are still running and asks you to restart them (firefox, gdm, etc.) . Solidifying syntax criteria why do we put unfixed in the brackets? makes parsing harder, etc. part of the problem we have two or three different parsers and we said yesterday that it wold be good to standardize/stabalize our formats. Moritz will make a proposal of fixes after studying them. Need to convert in parallel the information formerly included in NOTE:s into not-affected and possibly also converting some; severities from low into unimportant . Collaborative repository of security patches It was discussed how it would be nice to share a repository with Ubuntu, and others, that would contain security patches. Because finding patches takes too much time (digging in Bugzilla for half an hour is a pain, but needing to get a SuSe src RPM and extract it and try to find the patches they applied is insanity). If we created a repository that Debian and Ubuntu uses to share patches, it would then be made available to others so that everyone can benefit. . Sid tracking page Joey modified the script that makes the tracking page so that it can be generated for sid as well, it contains all the hurd holes, yay! http://spohr.debian.org/~joeyh/unstable-security.html . BTS bug severity As the testing-security team ends up looking at a significant number of the bugs tagged with +security, it would be good if we were versed in the proper severity levels so we can help adjust them and educate people as to what the proper severity levels for security issues should be: * affects a user that installs a package: critical * affects a user that has executed a binary, allowing compromising userdata, taking over account, etc.: grave * affects build-process, or generally annoying: important . Adding HELP tag It was discussed to add a HELP tag so that we can generate a page of issues (such as all x400 embedded source) that we need help with so other people can look and see what we could use general help with. . Filtering bug-dist Setup a mailing list that is subscribed to bug-dist that automatically filters out all emails except those which include tag +security and those that contain bug numbers that are listed in CAN/list . Publishing the testing-security''s severity levels We discussed the severity levels that we use in our tracking, and Micah agreed to dig out the discussions from the mailing list and compile them all together so we can agree on them and make them documented. low - not bad XSS issues medium - things that are local security high - remote holes/DoS (would rather terminate the service rather than run a insecure version) . Dealing with the upcoming CVE naming scheme change This happens October 19th. They will probably rename files - which will break our update scripts our CVE list will probably get all the CANs dumped into it, because they are renaming it Joeyh will contact steve@mitre about what will be happening so we can deal with it in advance update everything that says CANs with CVE there will be mappings from old CAN numbers to the new CVEs there should be a special announcement from us about the change when it happens . Florian''s tracker Move florian''s stuff to secure-testing website then (need to find out what the resource issues are with the tracker), need to keep aba in the loop for moving . Getting PTS to include a link from existing packages to their security history from Florian''s tracker. Need to contact hertzog@debian (buxy) about this once the tracker has been "finalized" and put somewhere stable . Need to discuss embedded source copies with martin pitt to see if we can create a common list of these . Dealing with removed packages? aptitude lists removed packages it lists security updates for stable, but not testing - but its an ugly hack (should instead use the Release file?) publish removed packages so that people know . Testing-security apt pinning issue aba will look into fixing the pinning issue - you can''t pin against release name, or code-name (etch), but only against the suite name (testing), aba will look into making the pinning for etch-seucre mirror the way it works in testing . Adding fixed in stable in the list? Need to talk to joey and mpitti about this so we can support other distributions. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20050924/5cf8ed48/attachment.pgp