Re: debian/kernel security issues (Was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
Hi! Andres Salomon [2005-03-16 2:43 -0500]: > You seem to be implying that ubuntu is providing you with confidential > prior warning about kernel security holes, but I really doubt this, > >>> > >> > >> Actually, that was the case for a while (before ubuntu's kernel team went > >> on vacation, and I went on vacation). However, w/ all the vacations > >> that have been happening, it hasn't been the case for a few months. > >> > >> > > > > Rather, I was mistaken; they were things that had already been made > > public. Right, I never gave away details about undisclosed issues. At most I said to you "hey, there is another issue that will be published in two days, so rather wait with an upload". > > And, as a perfect example; > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0210 > > This has already been made public, and has been fixed in Ubuntu kernels > for 2 days. Sure would be nice the cve folks to let the rest of us in on > it, eh? Mitre generally lacks behind fairly badly with this. I think it is genrally easier to coordinate with the Ubuntu kernel and security teams. I track all issues that affect the Ubuntu kernel (which mostly affect Debian as well) and generally know patch URLS etc. Also, you can always get patches from the source packages, or get them from the arch repository. But in the long run I think it would be easier to apply for vendor-sec subscription. Joey is already subscribed, but since he does not deal with unstable updates, it would be good to have Andres on board. Personally I would apreciate and support Andres' subscription to vendor-sec. Martin -- Martin Pitt http://www.piware.de Ubuntu Developerhttp://www.ubuntulinux.org Debian GNU/Linux Developer http://www.debian.org signature.asc Description: Digital signature
Re: debian/kernel security issues (Was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
Andres Salomon wrote: > Actually, that was the case for a while (before ubuntu's kernel team went > on vacation, and I went on vacation). However, w/ all the vacations > that have been happening, it hasn't been the case for a few months. Well it sounds like the earlier suggestion to get Joey to feed vuln info to someone on the kernel team (perhaps you for 2.6 and Horms for 2.4) would be a good idea. Assuming he's been able to keep up with recent kernel security holes. > Unfortunately, we don't have any real database of vulnerabilties to ensure > that they're fixed. I've been using > http://people.ubuntu.com/~pitti/ubuntu-cve.html, but that's about it. I hope you're aware of http://newraff.debian.org/~joeyh/testing-security.html ? It's true that this has the CVE lag built into it[1]. However it also has some unresolved kernel security issues listed. We could probably autogenerate a list of CANs of kernel holes that have not been verified to affect Debian kernels yet, if that would be helpful. -- see shy jo [1] To some extent; if I see an advisory that mentions a CAN it will get listed even if the CAN is still reserved. signature.asc Description: Digital signature
Re: debian/kernel security issues (Was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
On Wed, 16 Mar 2005 02:14:07 -0500, Andres Salomon wrote: > On Wed, 16 Mar 2005 01:38:48 -0500, Andres Salomon wrote: > >> On Tue, 15 Mar 2005 10:35:19 +0100, Sven Luther wrote: >> >>> On Tue, Mar 15, 2005 at 04:21:21AM -0500, Joey Hess wrote: Sven Luther wrote: >> [...] > > This is not a ubuntu related problem though, and the help the ubuntu > kernel/security team has provided us was invaluable, but it should maybe > not > be necessary if the information was not unrightfully hold from us in the > first > time. You seem to be implying that ubuntu is providing you with confidential prior warning about kernel security holes, but I really doubt this, >>> >> >> Actually, that was the case for a while (before ubuntu's kernel team went >> on vacation, and I went on vacation). However, w/ all the vacations >> that have been happening, it hasn't been the case for a few months. >> >> > > Rather, I was mistaken; they were things that had already been made > public. And, as a perfect example; http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0210 This has already been made public, and has been fixed in Ubuntu kernels for 2 days. Sure would be nice the cve folks to let the rest of us in on it, eh? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian/kernel security issues (Was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
On Wed, 16 Mar 2005 01:38:48 -0500, Andres Salomon wrote: > On Tue, 15 Mar 2005 10:35:19 +0100, Sven Luther wrote: > >> On Tue, Mar 15, 2005 at 04:21:21AM -0500, Joey Hess wrote: >>> Sven Luther wrote: > [...] >>> > >>> > This is not a ubuntu related problem though, and the help the ubuntu >>> > kernel/security team has provided us was invaluable, but it should maybe >>> > not >>> > be necessary if the information was not unrightfully hold from us in the >>> > first >>> > time. >>> >>> You seem to be implying that ubuntu is providing you with confidential >>> prior warning about kernel security holes, but I really doubt this, >> > > Actually, that was the case for a while (before ubuntu's kernel team went > on vacation, and I went on vacation). However, w/ all the vacations > that have been happening, it hasn't been the case for a few months. > > Rather, I was mistaken; they were things that had already been made public. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian/kernel security issues (Was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
On Tue, 15 Mar 2005 10:35:19 +0100, Sven Luther wrote: > On Tue, Mar 15, 2005 at 04:21:21AM -0500, Joey Hess wrote: >> Sven Luther wrote: [...] >> > >> > This is not a ubuntu related problem though, and the help the ubuntu >> > kernel/security team has provided us was invaluable, but it should maybe >> > not >> > be necessary if the information was not unrightfully hold from us in the >> > first >> > time. >> >> You seem to be implying that ubuntu is providing you with confidential >> prior warning about kernel security holes, but I really doubt this, > Actually, that was the case for a while (before ubuntu's kernel team went on vacation, and I went on vacation). However, w/ all the vacations that have been happening, it hasn't been the case for a few months. > Nope, but i was at one time hinted that i should wait a couple of days > before starting a 12 hours build. > >> since many of the ubuntu secutity advisories that I've backchecked >> against the debian kernels have turned out to still be unfixed in the >> kernel teams's svn weeks later. > > There is nobody actively doing debian security for unstable kernels > right now, well, not consistently, and not with the kind of advance > warning that is needed. This is rather a disapointement, i believe. But > i understand that our security team doesn't want or can care about > unstable/testing security updates. Unfortunately, we don't have any real database of vulnerabilties to ensure that they're fixed. I've been using http://people.ubuntu.com/~pitti/ubuntu-cve.html, but that's about it. The official CAN database is close to useless, as the CAN descriptions are generally not publically available for weeks after the vulnerability is publically known. As well, each kernel release is quite a pain due to the time involved in building and coordination across architectures (I've had my releases tagged and then backed out, for example); so, that combined w/ the rate of kernel vulnerability generally means we stick to a release schedule of once or twice a month for each kernel (which ranges from 2 or 3, since we have to track 2.6.8 specifically for sarge, as well as the latest 2.6.x kernel, plus 2.6.x-1 if 2.6.x is rotting in NEW). We end up having anywhere from 5-10 security-related patches in each release. For example, I just released kernel-source 2.6.8-14, but have not bothered to build a kernel-image for i386 yet, as horms committed another security fix to SVN for -15 about a day after I released. Instead, I guess I'll make sure he doesn't have any further commits, check ubuntu's latest kernel advisories, talk to pitti to make sure he doesn't have anything pending, release -15, and try for an i386 image at that point. This i386 image will, of course, have to sit around in NEW for a bit, as the ABINAME needs to be bumped by at least 2 different security related patches in -14. After that, I'll try some sparc kernel-images for 2.6.8 and 2.6.10. And after that, I may even get the chance to look at 2.6.11, but I doubt it; I'll probably leave that to svenl or something. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian/kernel security issues (Was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
On Tue, 15 Mar 2005 08:51:30 -0800, Matt Zimmerman wrote: > On Tue, Mar 15, 2005 at 09:50:22AM +0100, Sven Luther wrote: [...] > >> To have proper security-in-testing-or-unstable for the kernel, the >> debian-kernel security team, or at least a few members of it, need to be made >> aware of the embargoed security holes, and get a chance to fix them in >> advance, maybe with a private or security non-public copy of our svn tree >> (using svk maybe). > > Herbert Xu used to fill this role. After he resigned, William Lee Irwin (I > believe) volunteered to be the point of contact for security issues. If > William is not active in this role, the kernel team should nominate someone > else who can be trusted by the security team to work on sensitive issues, > and have them contact the security team. I have contacted Joey about this. He said he would try and keep me in the loop when he remembers, which is not quite what I was hoping for. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian/kernel security issues (Was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
On Tue, Mar 15, 2005 at 08:51:30AM -0800, Matt Zimmerman wrote: > On Tue, Mar 15, 2005 at 09:50:22AM +0100, Sven Luther wrote: > > > On Mon, Mar 14, 2005 at 04:51:55PM -0800, Matt Zimmerman wrote: > > > On Tue, Mar 15, 2005 at 01:14:30AM +0100, Sven Luther wrote: > > > > > > > On Mon, Mar 14, 2005 at 06:10:30PM -0500, Andres Salomon wrote: > > > > > Yes, I would like to reiterate that coordination between Martin Pitt, > > > > > the > > > > > Ubuntu kernel team, and the Debian kernel team has been an invaluable > > > > > resource for Debian; there are a lot of security fixes in Debian > > > > > kernels that were brought to my attention by either Fabio or Martin. > > > > > > > > Because they are in the security-announce-loop and we are not though, > > > > right ? > > > > > > Can you restate the question more clearly? In particular, expand the > > > pronouns "they" and "we", and explain what the security-announce-loop is. > > > > There is this vendor-specific-security-announce-with-embargo thingy. > > ...which is the subject of a lot of unfounded speculation by those who are > not familiar with the process. > > > To have proper security-in-testing-or-unstable for the kernel, the > > debian-kernel security team, or at least a few members of it, need to be > > made > > aware of the embargoed security holes, and get a chance to fix them in > > advance, maybe with a private or security non-public copy of our svn tree > > (using svk maybe). > > Herbert Xu used to fill this role. After he resigned, William Lee Irwin (I > believe) volunteered to be the point of contact for security issues. If > William is not active in this role, the kernel team should nominate someone > else who can be trusted by the security team to work on sensitive issues, > and have them contact the security team. > > > This is not a ubuntu related problem though, and the help the ubuntu > > kernel/security team has provided us was invaluable, but it should maybe not > > be necessary if the information was not unrightfully hold from us in the > > first > > time. > > This problem has nothing whatsoever to do with Ubuntu, and I appreciate you > retracting this implication. Whether you believe in coordinated disclosure > is equally irrelevant; the terms of such information is set by the rightful > party (e.g., the person who discovered it), and to violate those terms would > represent a breach of trust. I never made any such implication, not even sure what implication you are speaking about here. I only mentioned that the current kernel team has no access to the vendor-sec stuff, and as such it is logical that the help flows from ubuntu (who has access to it, right ?) since the ubuntu kernel team has a couple of weeks advance notice of the problems. Other problems also flow the other way around though. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian/kernel security issues (Was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
On Tue, Mar 15, 2005 at 09:50:22AM +0100, Sven Luther wrote: > On Mon, Mar 14, 2005 at 04:51:55PM -0800, Matt Zimmerman wrote: > > On Tue, Mar 15, 2005 at 01:14:30AM +0100, Sven Luther wrote: > > > > > On Mon, Mar 14, 2005 at 06:10:30PM -0500, Andres Salomon wrote: > > > > Yes, I would like to reiterate that coordination between Martin Pitt, > > > > the > > > > Ubuntu kernel team, and the Debian kernel team has been an invaluable > > > > resource for Debian; there are a lot of security fixes in Debian > > > > kernels that were brought to my attention by either Fabio or Martin. > > > > > > Because they are in the security-announce-loop and we are not though, > > > right ? > > > > Can you restate the question more clearly? In particular, expand the > > pronouns "they" and "we", and explain what the security-announce-loop is. > > There is this vendor-specific-security-announce-with-embargo thingy. ...which is the subject of a lot of unfounded speculation by those who are not familiar with the process. > To have proper security-in-testing-or-unstable for the kernel, the > debian-kernel security team, or at least a few members of it, need to be made > aware of the embargoed security holes, and get a chance to fix them in > advance, maybe with a private or security non-public copy of our svn tree > (using svk maybe). Herbert Xu used to fill this role. After he resigned, William Lee Irwin (I believe) volunteered to be the point of contact for security issues. If William is not active in this role, the kernel team should nominate someone else who can be trusted by the security team to work on sensitive issues, and have them contact the security team. > This is not a ubuntu related problem though, and the help the ubuntu > kernel/security team has provided us was invaluable, but it should maybe not > be necessary if the information was not unrightfully hold from us in the first > time. This problem has nothing whatsoever to do with Ubuntu, and I appreciate you retracting this implication. Whether you believe in coordinated disclosure is equally irrelevant; the terms of such information is set by the rightful party (e.g., the person who discovered it), and to violate those terms would represent a breach of trust. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian/kernel security issues (Was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
On Tue, Mar 15, 2005 at 04:21:21AM -0500, Joey Hess wrote: > Sven Luther wrote: > > There is this vendor-specific-security-announce-with-embargo thingy. > > > > The debian kernel team mostly handles the unstable and testing kernel, is > > not > > in the loop for getting advance advice on those problems, so we cannot build > > fixed versions until the vulnerability gets announced, and thus we can't > > upload kernels in a timely fashion like ubuntu or other vendors do, who > > often > > have a couple week of advance warnings. On slower arches this could be a > > problem. > > > > The debian-security team is handling stable only, and there are no security > > updates for unstable until way after the embargo is over, and for testing a > > bit after that, depending if the kernels get hinted in or not. > > > > To have proper security-in-testing-or-unstable for the kernel, the > > debian-kernel security team, or at least a few members of it, need to be > > made > > aware of the embargoed security holes, and get a chance to fix them in > > advance, maybe with a private or security non-public copy of our svn tree > > (using svk maybe). > > > > This is not a ubuntu related problem though, and the help the ubuntu > > kernel/security team has provided us was invaluable, but it should maybe not > > be necessary if the information was not unrightfully hold from us in the > > first > > time. > > You seem to be implying that ubuntu is providing you with confidential > prior warning about kernel security holes, but I really doubt this, Nope, but i was at one time hinted that i should wait a couple of days before starting a 12 hours build. > since many of the ubuntu secutity advisories that I've backchecked > against the debian kernels have turned out to still be unfixed in the > kernel teams's svn weeks later. There is nobody actively doing debian security for unstable kernels right now, well, not consistently, and not with the kind of advance warning that is needed. This is rather a disapointement, i believe. But i understand that our security team doesn't want or can care about unstable/testing security updates. > My experience is that the kernel security team is not very quick to fix > publically known security holes, or to make uploads specifically for > those holes once they have a fix. Even if we limit it to fixing the > kernel-source packages and ignore the whole issue of rebuilding > kernel-image packages for all arches. No, but it is coming, and should be improved post-sarge hopefully. The kernel-team has come a long way since Herbert abandoned it for chinese-internal-political-differences, but there is still no real interaction between the kernel-team and the security team. Still, people on the vendor list or whatever have weeks advance knowledge of those security problems. Also, as said, post-sarge the rebuild issues will be fixed by a single kernel package infrastructure, altough i am not sure how our auto-builders will support that, but we will see. The sarge kernel is mostly frozen anyway so it is out of our hands. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian/kernel security issues (Was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
Sven Luther wrote: > There is this vendor-specific-security-announce-with-embargo thingy. > > The debian kernel team mostly handles the unstable and testing kernel, is not > in the loop for getting advance advice on those problems, so we cannot build > fixed versions until the vulnerability gets announced, and thus we can't > upload kernels in a timely fashion like ubuntu or other vendors do, who often > have a couple week of advance warnings. On slower arches this could be a > problem. > > The debian-security team is handling stable only, and there are no security > updates for unstable until way after the embargo is over, and for testing a > bit after that, depending if the kernels get hinted in or not. > > To have proper security-in-testing-or-unstable for the kernel, the > debian-kernel security team, or at least a few members of it, need to be made > aware of the embargoed security holes, and get a chance to fix them in > advance, maybe with a private or security non-public copy of our svn tree > (using svk maybe). > > This is not a ubuntu related problem though, and the help the ubuntu > kernel/security team has provided us was invaluable, but it should maybe not > be necessary if the information was not unrightfully hold from us in the first > time. You seem to be implying that ubuntu is providing you with confidential prior warning about kernel security holes, but I really doubt this, since many of the ubuntu secutity advisories that I've backchecked against the debian kernels have turned out to still be unfixed in the kernel teams's svn weeks later. My experience is that the kernel security team is not very quick to fix publically known security holes, or to make uploads specifically for those holes once they have a fix. Even if we limit it to fixing the kernel-source packages and ignore the whole issue of rebuilding kernel-image packages for all arches. -- see shy jo signature.asc Description: Digital signature
debian/kernel security issues (Was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
On Mon, Mar 14, 2005 at 04:51:55PM -0800, Matt Zimmerman wrote: > On Tue, Mar 15, 2005 at 01:14:30AM +0100, Sven Luther wrote: > > > On Mon, Mar 14, 2005 at 06:10:30PM -0500, Andres Salomon wrote: > > > Yes, I would like to reiterate that coordination between Martin Pitt, the > > > Ubuntu kernel team, and the Debian kernel team has been an invaluable > > > resource for Debian; there are a lot of security fixes in Debian > > > kernels that were brought to my attention by either Fabio or Martin. > > > > Because they are in the security-announce-loop and we are not though, right > > ? > > Can you restate the question more clearly? In particular, expand the > pronouns "they" and "we", and explain what the security-announce-loop is. There is this vendor-specific-security-announce-with-embargo thingy. The debian kernel team mostly handles the unstable and testing kernel, is not in the loop for getting advance advice on those problems, so we cannot build fixed versions until the vulnerability gets announced, and thus we can't upload kernels in a timely fashion like ubuntu or other vendors do, who often have a couple week of advance warnings. On slower arches this could be a problem. The debian-security team is handling stable only, and there are no security updates for unstable until way after the embargo is over, and for testing a bit after that, depending if the kernels get hinted in or not. To have proper security-in-testing-or-unstable for the kernel, the debian-kernel security team, or at least a few members of it, need to be made aware of the embargoed security holes, and get a chance to fix them in advance, maybe with a private or security non-public copy of our svn tree (using svk maybe). This is not a ubuntu related problem though, and the help the ubuntu kernel/security team has provided us was invaluable, but it should maybe not be necessary if the information was not unrightfully hold from us in the first time. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
