FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 02-08-2011, 03:03 AM
Michael Gilbert
 
Default For discussion: security support strategy for the wheezy kernel

On Mon, 7 Feb 2011 22:54:53 -0500 Michael Gilbert wrote:
> Even playing the numbers game with a bit more thoughtful analysis with
> the LWN data, lenny looks a lot better. It can be seen that lenny
> (2.6.26) was vulnerable to 69% (36 out of 52) of the vulnerabilities
> listed there, and squeeze (2.6.32) was vulnerable to 98% (51 out of
> 52). In my opinion that's a rather substantial difference, and thus a
> problem worth pondering.

Minor correction: lenny was vulnerable to 67% (35 out of 51) and
squeeze was vulnerable to 98% (50 out of 51). I had missed the issue
that was fixed in 2.6.20 and didn't affect either releases.

Best wishes,
Mike


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110207230314.c81daa29.michael.s.gilbert@gmail.co m">http://lists.debian.org/20110207230314.c81daa29.michael.s.gilbert@gmail.co m
 
Old 02-18-2011, 09:24 PM
Michael Gilbert
 
Default For discussion: security support strategy for the wheezy kernel

On Mon, 7 Feb 2011 22:54:53 -0500 Michael Gilbert wrote:
> On Sun, 6 Feb 2011 21:58:08 -0400, Joey Hess wrote:
> > Michael Gilbert wrote:
> > > Another issue was that a lot of vulnerabilities that were found in that
> > > time frame were actually flaws in new kernel code, so testing/unstable
> > > were vulnerable, but the stable kernel itself was unaffected, so it was
> > > a bit safer to be running the stable kernel since the code was older
> > > (i.e. there was more time to find and fix issues). For example, the
> > > vulnerability for one of the local privilege escalations that was
> > > exploited in the wild was introduced in 2.6.30, so lenny wasn't
> > > affected, but testing/unstable were.
> >
> > LWN's analysis of age of introduction of kernel security holes in 2010
> > doesn't seem to agree? http://lwn.net/Articles/410606/
> >
> > | So, in a sense, the above-mentioned kernel hacker was correct - an
> > | awful lot of the vulnerabilities fixed over the last year predate the
> > | git era, and are thus over five years old.
>
> LWN's analysis is far from comprehensive, and the conclusions are not
> based in sufficiently rigorous analysis, but instead on the usual
> numbers game. Their reporting is however very useful as a basis for
> further research.
>
> The first fact that they completely miss is that not all CVEs are
> created equal. A memory info disclosure gets a CVE just like a
> privilege escalation that has known exploits, but both are on the same
> playing field in the numbers game. Annecdotally, CVE-2010-3301 and
> CVE-2010-1146 had an exploit in the wild, and 2.6.26 was never
> affected. The only issue that had an in-the-wild exploit affecting
> lenny in that list (that I'm aware of) was CVE-2010-3081 (and lenny
> would have sidestepped that too if it had had been even more
> conservative and gone with the older/stabler 2.6.25).
>
> Even playing the numbers game with a bit more thoughtful analysis with
> the LWN data, lenny looks a lot better. It can be seen that lenny
> (2.6.26) was vulnerable to 69% (36 out of 52) of the vulnerabilities
> listed there, and squeeze (2.6.32) was vulnerable to 98% (51 out of
> 52). In my opinion that's a rather substantial difference, and thus a
> problem worth pondering.

So, now that I've had some time to contemplate the replies on this
issue, I have a much better appreciation of the need to keep unstable
closely in line with upstream development, and thus don't want to push
the original solution anymore. Also 2.6.37 is in unstable now, so that
idea is impossible, which is OK.

However, as I justify above, there is still a problem, and I think it
can still be solved relatively easily and without too much impact.
This time I suggest blocking 2.6.37 so 2.6.32 remains in testing for a
while. This will allow it to get updates in sync with stable kernel
security updates (without any additional effort by Dann, Moritz, and
other kernel team members other than the package upload to testing as
well).

This will also help to provide a bit more stability for CUT [0]. Over
a 1.5-year period (the non-freeze timeframe) roughly 6 new upstream
kernels will be released, and each new kernel comes along with a high
probability of introducing breakage. I'm trying to provide CUT
releases once a month, so every 3 months I will be looking at a likely
broken CUT release (or 25% of the time). However, if there is just one
kernel transition in testing development cycle, then there is only 1
likely broken period (or 4% of the time).

Anyway, I know that the fact that this may have a future effect on my
efforts isn't a great argument, but this does impact whether CUT will be
successful, which impacts the whole project. I wonder if we can at
least try it for a few months, and if there really are problems with
keeping the old kernel in testing, then we can just end this experiment
and unblock the newer upstream version.

If there is some concurrence on this, I'll submit an RC blocker bug on
the kernel. Note there are only 8 days to discuss before the
transition is automatic (I think the current RC blocker [1] may
disappear by then).

Best wishes,
Mike

[0] http://lists.alioth.debian.org/pipermail/cut-team/2011-February/000195.html
[1] http://qa.debian.org/excuses.php?package=linux-2.6


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110218172432.239da727.michael.s.gilbert@gmail.co m">http://lists.debian.org/20110218172432.239da727.michael.s.gilbert@gmail.co m
 
Old 02-18-2011, 10:11 PM
Ben Hutchings
 
Default For discussion: security support strategy for the wheezy kernel

On Fri, 2011-02-18 at 17:24 -0500, Michael Gilbert wrote:
[...]
> If there is some concurrence on this, I'll submit an RC blocker bug on
> the kernel. Note there are only 8 days to discuss before the
> transition is automatic (I think the current RC blocker [1] may
> disappear by then).

I don't recall anyone agreeing with your idea to stop following
upstream. Please let this drop.

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
 
Old 02-19-2011, 05:47 AM
Lucas Nussbaum
 
Default For discussion: security support strategy for the wheezy kernel

On 18/02/11 at 17:24 -0500, Michael Gilbert wrote:
> On Mon, 7 Feb 2011 22:54:53 -0500 Michael Gilbert wrote:
> > On Sun, 6 Feb 2011 21:58:08 -0400, Joey Hess wrote:
> > > Michael Gilbert wrote:
> > > > Another issue was that a lot of vulnerabilities that were found in that
> > > > time frame were actually flaws in new kernel code, so testing/unstable
> > > > were vulnerable, but the stable kernel itself was unaffected, so it was
> > > > a bit safer to be running the stable kernel since the code was older
> > > > (i.e. there was more time to find and fix issues). For example, the
> > > > vulnerability for one of the local privilege escalations that was
> > > > exploited in the wild was introduced in 2.6.30, so lenny wasn't
> > > > affected, but testing/unstable were.
> > >
> > > LWN's analysis of age of introduction of kernel security holes in 2010
> > > doesn't seem to agree? http://lwn.net/Articles/410606/
> > >
> > > | So, in a sense, the above-mentioned kernel hacker was correct - an
> > > | awful lot of the vulnerabilities fixed over the last year predate the
> > > | git era, and are thus over five years old.
> >
> > LWN's analysis is far from comprehensive, and the conclusions are not
> > based in sufficiently rigorous analysis, but instead on the usual
> > numbers game. Their reporting is however very useful as a basis for
> > further research.
> >
> > The first fact that they completely miss is that not all CVEs are
> > created equal. A memory info disclosure gets a CVE just like a
> > privilege escalation that has known exploits, but both are on the same
> > playing field in the numbers game. Annecdotally, CVE-2010-3301 and
> > CVE-2010-1146 had an exploit in the wild, and 2.6.26 was never
> > affected. The only issue that had an in-the-wild exploit affecting
> > lenny in that list (that I'm aware of) was CVE-2010-3081 (and lenny
> > would have sidestepped that too if it had had been even more
> > conservative and gone with the older/stabler 2.6.25).
> >
> > Even playing the numbers game with a bit more thoughtful analysis with
> > the LWN data, lenny looks a lot better. It can be seen that lenny
> > (2.6.26) was vulnerable to 69% (36 out of 52) of the vulnerabilities
> > listed there, and squeeze (2.6.32) was vulnerable to 98% (51 out of
> > 52). In my opinion that's a rather substantial difference, and thus a
> > problem worth pondering.
>
> So, now that I've had some time to contemplate the replies on this
> issue, I have a much better appreciation of the need to keep unstable
> closely in line with upstream development, and thus don't want to push
> the original solution anymore. Also 2.6.37 is in unstable now, so that
> idea is impossible, which is OK.
>
> However, as I justify above, there is still a problem, and I think it
> can still be solved relatively easily and without too much impact.
> This time I suggest blocking 2.6.37 so 2.6.32 remains in testing for a
> while. This will allow it to get updates in sync with stable kernel
> security updates (without any additional effort by Dann, Moritz, and
> other kernel team members other than the package upload to testing as
> well).

You base your reasoning on the assumption that CUT users prefer a more
stable kernel to a more recent kernel. I'm tempted to think the
opposite.

- lucas


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110219064759.GA30603@xanadu.blop.info">http://lists.debian.org/20110219064759.GA30603@xanadu.blop.info
 
Old 02-19-2011, 12:09 PM
Raphael Hertzog
 
Default For discussion: security support strategy for the wheezy kernel

On Fri, 18 Feb 2011, Michael Gilbert wrote:
> This will also help to provide a bit more stability for CUT [0]. Over
> a 1.5-year period (the non-freeze timeframe) roughly 6 new upstream
> kernels will be released, and each new kernel comes along with a high
> probability of introducing breakage. I'm trying to provide CUT
> releases once a month, so every 3 months I will be looking at a likely
> broken CUT release (or 25% of the time). However, if there is just one
> kernel transition in testing development cycle, then there is only 1
> likely broken period (or 4% of the time).

The kernel is not the sole component that can introduce breakage. So it
seems ridiculous to do such statistics based on the kernel only.

And like Lucas said, CUT users want recent software and that includes the
kernel (which is also important for new hardware support).

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110219130950.GA32535@rivendell.home.ouaza.com">h ttp://lists.debian.org/20110219130950.GA32535@rivendell.home.ouaza.com
 
Old 02-19-2011, 05:12 PM
Michael Gilbert
 
Default For discussion: security support strategy for the wheezy kernel

On Sat, 19 Feb 2011 14:09:50 +0100 Raphael Hertzog wrote:

> On Fri, 18 Feb 2011, Michael Gilbert wrote:
> > This will also help to provide a bit more stability for CUT [0]. Over
> > a 1.5-year period (the non-freeze timeframe) roughly 6 new upstream
> > kernels will be released, and each new kernel comes along with a high
> > probability of introducing breakage. I'm trying to provide CUT
> > releases once a month, so every 3 months I will be looking at a likely
> > broken CUT release (or 25% of the time). However, if there is just one
> > kernel transition in testing development cycle, then there is only 1
> > likely broken period (or 4% of the time).
>
> The kernel is not the sole component that can introduce breakage. So it
> seems ridiculous to do such statistics based on the kernel only.

Hi Raphael, I completely concur that there are indeed other important
components like grub and xorg where breakage would be a showstopper.
However, I don't think the consequences would be quite so substantial.
There is just so much intimately dependent on the kernel that breakage
there has a very wide area of effect; whereas grub or xorg breakage is
somewhat contained. This is why I'm only significantly concerned about
the kernel. Anyway, I agree that there will be breakage, but I don't
want CUT to be mostly about constantly resolving the same repetitive
kernel breakage.

Also, this solution isn't just about CUT stability. As I've been
describing, it is about killing about 2 birds with one stone:

1. Make testing always installable by retaining a stable/well-tested
kernel and associated d-i infrastructure
2. Improve testing security by reducing the amount of vulnerabilities
existent in older kernels (roughly 67% fewer in 2.6.32 vs 2.6.37 as
described previously)

In fact these are two of the three known problems in testing mentioned
in your LWN article [0]. And the only consequence is that testing users
don't get the latest kernel bling. However, that is offset by the
availability of 2.6.37 and associated infrastructure in unstable. So
there really are no downsides that can't be worked around with a little
education/effort on the part of the user.

> And like Lucas said, CUT users want recent software and that includes the
> kernel

I don't think it is appropriate to project a singular perspective onto
all users. Ultimately our goal is to perform a balancing act between
freshness and stability. In the past the primary focus has been on
freshness in testing, but I think there is room to swing the pendulum a
bit more toward stability. It's really a requirement if we're ever
going to be able to achieve something a testing that's "constantly
usable". Also, users needing bleeding-edge freshness can always take
the plunge into unstable.

> (which is also important for new hardware support).

This seems to be a meme that continues to persist without much in the
way of evidence. It certainly may have been true in the past, but I
think things have changed for the better with the advent of stable
upstream support (i.e. support for new hardware is backported to the
stable kernels).

Also, I've read about 10 reviews of squeeze, and none of them have
indicated any problems with hardware support (except for missing
support for non-free firmware) even though that uses a kernel initially
released almost a year and a half ago. In fact, I've only ever had one
piece of hardware (a wireless card) that was unsupported by Debian, and
that was when sarge was still in testing, and all that was needed was
to enter the device id into the discover list. It wasn't even a kernel
issue.

Ultimately I don't see why the newest blingy kernel is a necessity in
testing.

Best wishes,
Mike

[0] http://lwn.net/Articles/406301/


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110219131235.1c8ee6b5.michael.s.gilbert@gmail.co m">http://lists.debian.org/20110219131235.1c8ee6b5.michael.s.gilbert@gmail.co m
 
Old 02-19-2011, 05:48 PM
Ben Hutchings
 
Default For discussion: security support strategy for the wheezy kernel

On Sat, 2011-02-19 at 13:12 -0500, Michael Gilbert wrote:
[...]
> Also, this solution isn't just about CUT stability. As I've been
> describing, it is about killing about 2 birds with one stone:
>
> 1. Make testing always installable by retaining a stable/well-tested
> kernel and associated d-i infrastructure

We do backport new hardware support to stable but we do not have the
resources (time and equipment) to cover everything. So this would mean
that neither stable nor testing would be installable on some newer
hardware.

> 2. Improve testing security by reducing the amount of vulnerabilities
> existent in older kernels (roughly 67% fewer in 2.6.32 vs 2.6.37 as
> described previously)

Huh? I don't see any source for this figure.

[...]
> > (which is also important for new hardware support).
>
> This seems to be a meme that continues to persist without much in the
> way of evidence. It certainly may have been true in the past, but I
> think things have changed for the better with the advent of stable
> upstream support (i.e. support for new hardware is backported to the
> stable kernels).
>
> Also, I've read about 10 reviews of squeeze, and none of them have
> indicated any problems with hardware support (except for missing
> support for non-free firmware) even though that uses a kernel initially
> released almost a year and a half ago.
[...]

I can assure you there is already a substantial backlog of new hardware
that is currently unsupported in squeeze. For example, any current ATI
graphics chip. And this is at the start of squeeze's lifetime, not the
end.

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
 
Old 02-19-2011, 06:04 PM
Michael Gilbert
 
Default For discussion: security support strategy for the wheezy kernel

On Sat, 19 Feb 2011 18:48:40 +0000 Ben Hutchings wrote:

> On Sat, 2011-02-19 at 13:12 -0500, Michael Gilbert wrote:
> [...]
> > Also, this solution isn't just about CUT stability. As I've been
> > describing, it is about killing about 2 birds with one stone:
> >
> > 1. Make testing always installable by retaining a stable/well-tested
> > kernel and associated d-i infrastructure
>
> We do backport new hardware support to stable but we do not have the
> resources (time and equipment) to cover everything. So this would mean
> that neither stable nor testing would be installable on some newer
> hardware.

Right, and in those rare cases, the user will have to sufficiently
educate themselves to be able to use unstable.

> > 2. Improve testing security by reducing the amount of vulnerabilities
> > existent in older kernels (roughly 67% fewer in 2.6.32 vs 2.6.37 as
> > described previously)
>
> Huh? I don't see any source for this figure.

http://lists.alioth.debian.org/pipermail/cut-team/2011-February/000193.html
http://lists.alioth.debian.org/pipermail/cut-team/2011-February/000194.html

> [...]
> > > (which is also important for new hardware support).
> >
> > This seems to be a meme that continues to persist without much in the
> > way of evidence. It certainly may have been true in the past, but I
> > think things have changed for the better with the advent of stable
> > upstream support (i.e. support for new hardware is backported to the
> > stable kernels).
> >
> > Also, I've read about 10 reviews of squeeze, and none of them have
> > indicated any problems with hardware support (except for missing
> > support for non-free firmware) even though that uses a kernel initially
> > released almost a year and a half ago.
> [...]
>
> I can assure you there is already a substantial backlog of new hardware
> that is currently unsupported in squeeze. For example, any current ATI
> graphics chip. And this is at the start of squeeze's lifetime, not the
> end.

I've been using ati cards exclusively for some time now; although I've
also been willing to install the fglrx driver for full support
Also, the xorg vesa driver does work.

Again, if the user is interested in such new developments, they will
need to be willing to learn how to run an unstable system.

Best wishes,
Mike


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110219140422.d87cadf7.michael.s.gilbert@gmail.co m">http://lists.debian.org/20110219140422.d87cadf7.michael.s.gilbert@gmail.co m
 
Old 02-19-2011, 06:32 PM
Ben Hutchings
 
Default For discussion: security support strategy for the wheezy kernel

On Sat, 2011-02-19 at 14:04 -0500, Michael Gilbert wrote:
> On Sat, 19 Feb 2011 18:48:40 +0000 Ben Hutchings wrote:
>
> > On Sat, 2011-02-19 at 13:12 -0500, Michael Gilbert wrote:
[...]
> > > 2. Improve testing security by reducing the amount of vulnerabilities
> > > existent in older kernels (roughly 67% fewer in 2.6.32 vs 2.6.37 as
> > > described previously)
> >
> > Huh? I don't see any source for this figure.
>
> http://lists.alioth.debian.org/pipermail/cut-team/2011-February/000193.html
> http://lists.alioth.debian.org/pipermail/cut-team/2011-February/000194.html

I read those and I can't see any source for comparison between 2.6.32
and 2.6.37. In fact you say that 'squeeze (2.6.32) was vulnerable to
98% (51 out of 52)' which implies only 2% fewer vulnerabilities.

> > [...]
> > > > (which is also important for new hardware support).
> > >
> > > This seems to be a meme that continues to persist without much in the
> > > way of evidence. It certainly may have been true in the past, but I
> > > think things have changed for the better with the advent of stable
> > > upstream support (i.e. support for new hardware is backported to the
> > > stable kernels).
> > >
> > > Also, I've read about 10 reviews of squeeze, and none of them have
> > > indicated any problems with hardware support (except for missing
> > > support for non-free firmware) even though that uses a kernel initially
> > > released almost a year and a half ago.
> > [...]
> >
> > I can assure you there is already a substantial backlog of new hardware
> > that is currently unsupported in squeeze. For example, any current ATI
> > graphics chip. And this is at the start of squeeze's lifetime, not the
> > end.
>
> I've been using ati cards exclusively for some time now; although I've
> also been willing to install the fglrx driver for full support

Then I really can't take your concern for security seriously. The
changelog for fglrx-source has no mention of security fixes, and I don't
for one moment believe there are no vulnerabilities in it.

> Also, the xorg vesa driver does work.

Seems like a waste of money to buy an ATI card and then use it as a dumb
framebuffer.

> Again, if the user is interested in such new developments, they will
> need to be willing to learn how to run an unstable system.

I thought that users interested in new stuff were supposed to run CUT.

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
 
Old 02-19-2011, 06:59 PM
Michael Gilbert
 
Default For discussion: security support strategy for the wheezy kernel

On Sat, 19 Feb 2011 19:32:08 +0000 Ben Hutchings wrote:

> On Sat, 2011-02-19 at 14:04 -0500, Michael Gilbert wrote:
> > On Sat, 19 Feb 2011 18:48:40 +0000 Ben Hutchings wrote:
> >
> > > On Sat, 2011-02-19 at 13:12 -0500, Michael Gilbert wrote:
> [...]
> > > > 2. Improve testing security by reducing the amount of vulnerabilities
> > > > existent in older kernels (roughly 67% fewer in 2.6.32 vs 2.6.37 as
> > > > described previously)
> > >
> > > Huh? I don't see any source for this figure.
> >
> > http://lists.alioth.debian.org/pipermail/cut-team/2011-February/000193.html
> > http://lists.alioth.debian.org/pipermail/cut-team/2011-February/000194.html
>
> I read those and I can't see any source for comparison between 2.6.32
> and 2.6.37. In fact you say that 'squeeze (2.6.32) was vulnerable to
> 98% (51 out of 52)' which implies only 2% fewer vulnerabilities.

I suppose the way I said that is confusing. That research was from
past results, and my latest statement is a projection based on the
past. In other words, if lenny was vulnerable to 67% of the issues that
squeeze was, I'm projecting that it will be similar for squeeze: it
will be vulnerable to about 67% of the issues that wheezy will;
although that could be +-10%, +-20%, who knows since events have yet
to happen.

> > I've been using ati cards exclusively for some time now; although I've
> > also been willing to install the fglrx driver for full support
>
> Then I really can't take your concern for security seriously. The
> changelog for fglrx-source has no mention of security fixes, and I don't
> for one moment believe there are no vulnerabilities in it.

Well, that's a risk I'm willing to accept for myself. Others may have a
differing perspective, and that's fine. My risk mitigation strategy
should have nothing to do with the rest of the project's.

> > Also, the xorg vesa driver does work.
>
> Seems like a waste of money to buy an ATI card and then use it as a dumb
> framebuffer.

Not all ati cards are top of the line, and not all users need 3D anyway.

> > Again, if the user is interested in such new developments, they will
> > need to be willing to learn how to run an unstable system.
>
> I thought that users interested in new stuff were supposed to run CUT.

Most packages will in fact be new, just the kernel and reverse
dependencies will be held back. Hence CUT users will get 99% new
stuff (with respect to stable), and a tiny bit held back simply for
stability. Like I've said a couple times now, its a balancing act.

All I'm asking for is a few month long experiment. And if the
experiment shows signs of flaws/weaknesses, then the blocker can
certainly be lifted.

Best wishes,
Mike


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110219145927.3cda91e3.michael.s.gilbert@gmail.co m">http://lists.debian.org/20110219145927.3cda91e3.michael.s.gilbert@gmail.co m
 

Thread Tools




All times are GMT. The time now is 03:54 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org