This is the start of the review cycle for the stable 2.6.20.17
kernel release. This version catches up with 2.6.22.4, and 58
patches will be posted as a response to this message.
The following security issues are solved :
CVE-2007-3105
CVE-2007-3848
CVE-2007-3851
The rolled up patch can be found here :
ftp.kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.20.17-rc1.gz
Responses should be made by August 24, 2007, 19:00:00 UTC. Anything
received after that time might be too late.
Thanks,
Willy
--
Hi Willy,
On 22/08/07, Willy Tarreau <[email protected]> wrote:
> This is the start of the review cycle for the stable 2.6.20.17
> kernel release. This version catches up with 2.6.22.4, and 58
> patches will be posted as a response to this message.
>
> The following security issues are solved :
> CVE-2007-3105
> CVE-2007-3848
> CVE-2007-3851
>
> The rolled up patch can be found here :
> ftp.kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.20.17-rc1.gz
>
> Responses should be made by August 24, 2007, 19:00:00 UTC. Anything
> received after that time might be too late.
I got a problem with SELinux
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console.log
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/stable-config
rpm -qa selinux-policy*
selinux-policy-devel-2.6.4-33.fc7
selinux-policy-2.6.4-33.fc7
selinux-policy-targeted-2.6.4-33.fc7
I didn't tested 2.6.20.* since 2.6.20 release so it might take some
time to figure out.
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
Hi Michal,
On Wed, Aug 22, 2007 at 01:10:44PM +0200, Michal Piotrowski wrote:
> Hi Willy,
>
> On 22/08/07, Willy Tarreau <[email protected]> wrote:
> > This is the start of the review cycle for the stable 2.6.20.17
> > kernel release. This version catches up with 2.6.22.4, and 58
> > patches will be posted as a response to this message.
> >
> > The following security issues are solved :
> > CVE-2007-3105
> > CVE-2007-3848
> > CVE-2007-3851
> >
> > The rolled up patch can be found here :
> > ftp.kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.20.17-rc1.gz
> >
> > Responses should be made by August 24, 2007, 19:00:00 UTC. Anything
> > received after that time might be too late.
>
> I got a problem with SELinux
> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console.log
> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/stable-config
>
> rpm -qa selinux-policy*
> selinux-policy-devel-2.6.4-33.fc7
> selinux-policy-2.6.4-33.fc7
> selinux-policy-targeted-2.6.4-33.fc7
>
> I didn't tested 2.6.20.* since 2.6.20 release so it might take some
> time to figure out.
I'm a total looser in selinux, so I'll not be able to help here. Could you
please test if 2.6.20.16 works ? It would at least tell us if it's one of
the patches in 17-rc1.
Thanks,
Willy
On Wed, 22 Aug 2007, Michal Piotrowski wrote:
> I got a problem with SELinux
> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console.log
> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/stable-config
Please set
CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT=n
You don't have complete policy for the new network controls, which are not
enabled by default and not integreated fully into distros yet.
--
James Morris
<[email protected]>
On Wed, 22 Aug 2007, James Morris wrote:
> On Wed, 22 Aug 2007, Michal Piotrowski wrote:
>
> > I got a problem with SELinux
> > http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console.log
> > http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/stable-config
>
> Please set
> CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT=n
>
> You don't have complete policy for the new network controls, which are not
> enabled by default and not integreated fully into distros yet.
Actually, this looks to be a bug where the secmark field of the skb is not
being initialized correctly. Patch coming soon...
--
James Morris
<[email protected]>
On Wed, 2007-08-22 at 06:23 -0700, James Morris wrote:
> On Wed, 22 Aug 2007, Michal Piotrowski wrote:
>
> > I got a problem with SELinux
> > http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console.log
> > http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/stable-config
>
> Please set
> CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT=n
>
> You don't have complete policy for the new network controls, which are not
> enabled by default and not integreated fully into distros yet.
Still, that denial shouldn't be against kernel_t unless he has iptables
SECMARK rules that assign that value.
It's the change to the skb allocator - no longer clears up through
truesize and thus secmark is garbage initially. That would apply to
mainline too.
--
Stephen Smalley
National Security Agency
On Wed, 2007-08-22 at 09:36 -0400, Stephen Smalley wrote:
> On Wed, 2007-08-22 at 06:23 -0700, James Morris wrote:
> > On Wed, 22 Aug 2007, Michal Piotrowski wrote:
> >
> > > I got a problem with SELinux
> > > http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console.log
> > > http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/stable-config
> >
> > Please set
> > CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT=n
> >
> > You don't have complete policy for the new network controls, which are not
> > enabled by default and not integreated fully into distros yet.
>
> Still, that denial shouldn't be against kernel_t unless he has iptables
> SECMARK rules that assign that value.
>
> It's the change to the skb allocator - no longer clears up through
> truesize and thus secmark is garbage initially. That would apply to
> mainline too.
Oops, never mind - tail still follows secmark, so that shouldn't matter.
So I'm not sure why we are getting a bad value for secmark here - should
be initialized to zero and never modified unless there is an iptables
secmark rule.
--
Stephen Smalley
National Security Agency
On Wed, 22 Aug 2007, Stephen Smalley wrote:
> Oops, never mind - tail still follows secmark, so that shouldn't matter.
> So I'm not sure why we are getting a bad value for secmark here - should
> be initialized to zero and never modified unless there is an iptables
> secmark rule.
Michal, do you see this in current git?
--
James Morris
<[email protected]>
On 22/08/07, James Morris <[email protected]> wrote:
> On Wed, 22 Aug 2007, Stephen Smalley wrote:
>
> > Oops, never mind - tail still follows secmark, so that shouldn't matter.
> > So I'm not sure why we are getting a bad value for secmark here - should
> > be initialized to zero and never modified unless there is an iptables
> > secmark rule.
>
> Michal, do you see this in current git?
No, I do not see this problem in 2.6.23. I had similar problem last
month, but it is fixed now.
http://lkml.org/lkml/2007/7/12/362
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
On Wed, 2007-08-22 at 16:29 +0200, Michal Piotrowski wrote:
> On 22/08/07, James Morris <[email protected]> wrote:
> > On Wed, 22 Aug 2007, Stephen Smalley wrote:
> >
> > > Oops, never mind - tail still follows secmark, so that shouldn't matter.
> > > So I'm not sure why we are getting a bad value for secmark here - should
> > > be initialized to zero and never modified unless there is an iptables
> > > secmark rule.
> >
> > Michal, do you see this in current git?
>
> No, I do not see this problem in 2.6.23. I had similar problem last
> month, but it is fixed now.
>
> http://lkml.org/lkml/2007/7/12/362
The difference being that there the denials were against unlabeled_t
(the expected default in the presence of no iptables SECMARK rules, and
allowed by current policies), while the denials against 2.6.20.17 were
against kernel_t. Which shouldn't ever happen unless you have an
iptables SECMARK rule that assigns that value to a packet. So this is a
different issue. BTW, the fact that it is showing up as kernel_t means
that skb->secmark == SECINITSID_KERNEL == 1, FWIW. Whereas it should be
zero in the absence of iptables rules that set it.
--
Stephen Smalley
National Security Agency
On Wed, 22 Aug 2007, Michal Piotrowski wrote:
> On 22/08/07, James Morris <[email protected]> wrote:
> > On Wed, 22 Aug 2007, Stephen Smalley wrote:
> >
> > > Oops, never mind - tail still follows secmark, so that shouldn't matter.
> > > So I'm not sure why we are getting a bad value for secmark here - should
> > > be initialized to zero and never modified unless there is an iptables
> > > secmark rule.
> >
> > Michal, do you see this in current git?
>
> No, I do not see this problem in 2.6.23. I had similar problem last
> month, but it is fixed now.
>
> http://lkml.org/lkml/2007/7/12/362
The previous problem is theoretically unrelated. It arose via a separate
mechanism which can't be used at the same as the one you're seeing now in
the logs.
So this either looks like a problem which has gone unnoticed and was
inadvertently fixed at some point, or is unique to the 2.6.20 stable
series.
- James
--
James Morris
<[email protected]>
On 22/08/07, James Morris <[email protected]> wrote:
> On Wed, 22 Aug 2007, Michal Piotrowski wrote:
>
> > On 22/08/07, James Morris <[email protected]> wrote:
> > > On Wed, 22 Aug 2007, Stephen Smalley wrote:
> > >
> > > > Oops, never mind - tail still follows secmark, so that shouldn't matter.
> > > > So I'm not sure why we are getting a bad value for secmark here - should
> > > > be initialized to zero and never modified unless there is an iptables
> > > > secmark rule.
> > >
> > > Michal, do you see this in current git?
> >
> > No, I do not see this problem in 2.6.23. I had similar problem last
> > month, but it is fixed now.
> >
> > http://lkml.org/lkml/2007/7/12/362
>
> The previous problem is theoretically unrelated. It arose via a separate
> mechanism which can't be used at the same as the one you're seeing now in
> the logs.
>
> So this either looks like a problem which has gone unnoticed and was
> inadvertently fixed at some point, or is unique to the 2.6.20 stable
> series.
Yup, it is very interesting why no one noticed it. Binary search in progress:
good - 2.6.20.4
bad - 2.6.20.8
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
On Wed, 22 Aug 2007, Michal Piotrowski wrote:
> Yup, it is very interesting why no one noticed it.
The new network controls are not enabled by default yet in distros.
- James
--
James Morris
<[email protected]>
On 22/08/07, Michal Piotrowski <[email protected]> wrote:
> On 22/08/07, James Morris <[email protected]> wrote:
[snip]
> > The previous problem is theoretically unrelated. It arose via a separate
> > mechanism which can't be used at the same as the one you're seeing now in
> > the logs.
> >
> > So this either looks like a problem which has gone unnoticed and was
> > inadvertently fixed at some point, or is unique to the 2.6.20 stable
> > series.
>
> Yup, it is very interesting why no one noticed it. Binary search in progress:
> good - 2.6.20.4
> bad - 2.6.20.8
Ok, I narrowed the problem to 2.6.20.7. There are a few net changes
http://eu.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.20.7
any suggestions?
I also have seen this avc on 2.6.20.6 during reboot
[ 2333.905944] audit(1187803699.273:271): avc: denied { send } for
saddr=192.168.1.70 src=48591 daddr=72.14.217.189 dest=80 netif=eth0
scontext=user_u:system_r:unconfined_t:s0
tcontext=system_u:system_r:kernel_t:s0 tclass=packet
[ 2334.420598] audit(1187803699.789:272): avc: denied { send } for
saddr=192.168.1.70 src=47248 daddr=66.249.91.18 dest=80 netif=eth0
scontext=user_u:system_r:unconfined_t:s0
tcontext=system_u:system_r:kernel_t:s0 tclass=packet
so the roots of the problem may lie between 2.6.20.4 and 2.6.20.6
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console2.log
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
On 22/08/07, James Morris <[email protected]> wrote:
> On Wed, 22 Aug 2007, Michal Piotrowski wrote:
>
> > Yup, it is very interesting why no one noticed it.
>
> The new network controls are not enabled by default yet in distros.
That's why I enable most of these unsupported features :)
Unfortunately, I don't have time to test all stable/development releases.
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
On Wed, 2007-08-22 at 19:50 +0200, Michal Piotrowski wrote:
> On 22/08/07, Michal Piotrowski <[email protected]> wrote:
> > On 22/08/07, James Morris <[email protected]> wrote:
> [snip]
> > > The previous problem is theoretically unrelated. It arose via a separate
> > > mechanism which can't be used at the same as the one you're seeing now in
> > > the logs.
> > >
> > > So this either looks like a problem which has gone unnoticed and was
> > > inadvertently fixed at some point, or is unique to the 2.6.20 stable
> > > series.
> >
> > Yup, it is very interesting why no one noticed it. Binary search in progress:
> > good - 2.6.20.4
> > bad - 2.6.20.8
>
> Ok, I narrowed the problem to 2.6.20.7. There are a few net changes
> http://eu.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.20.7
> any suggestions?
>
> I also have seen this avc on 2.6.20.6 during reboot
>
> [ 2333.905944] audit(1187803699.273:271): avc: denied { send } for
> saddr=192.168.1.70 src=48591 daddr=72.14.217.189 dest=80 netif=eth0
> scontext=user_u:system_r:unconfined_t:s0
> tcontext=system_u:system_r:kernel_t:s0 tclass=packet
> [ 2334.420598] audit(1187803699.789:272): avc: denied { send } for
> saddr=192.168.1.70 src=47248 daddr=66.249.91.18 dest=80 netif=eth0
> scontext=user_u:system_r:unconfined_t:s0
> tcontext=system_u:system_r:kernel_t:s0 tclass=packet
>
> so the roots of the problem may lie between 2.6.20.4 and 2.6.20.6
>
> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console2.log
Might be related to this:
http://marc.info/?l=git-commits-head&m=118271540932264&w=2
--
Stephen Smalley
National Security Agency
On Wed, Aug 22, 2007 at 03:15:14PM -0400, Stephen Smalley wrote:
> On Wed, 2007-08-22 at 19:50 +0200, Michal Piotrowski wrote:
> > On 22/08/07, Michal Piotrowski <[email protected]> wrote:
> > > On 22/08/07, James Morris <[email protected]> wrote:
> > [snip]
> > > > The previous problem is theoretically unrelated. It arose via a separate
> > > > mechanism which can't be used at the same as the one you're seeing now in
> > > > the logs.
> > > >
> > > > So this either looks like a problem which has gone unnoticed and was
> > > > inadvertently fixed at some point, or is unique to the 2.6.20 stable
> > > > series.
> > >
> > > Yup, it is very interesting why no one noticed it. Binary search in progress:
> > > good - 2.6.20.4
> > > bad - 2.6.20.8
> >
> > Ok, I narrowed the problem to 2.6.20.7. There are a few net changes
> > http://eu.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.20.7
> > any suggestions?
> >
> > I also have seen this avc on 2.6.20.6 during reboot
> >
> > [ 2333.905944] audit(1187803699.273:271): avc: denied { send } for
> > saddr=192.168.1.70 src=48591 daddr=72.14.217.189 dest=80 netif=eth0
> > scontext=user_u:system_r:unconfined_t:s0
> > tcontext=system_u:system_r:kernel_t:s0 tclass=packet
> > [ 2334.420598] audit(1187803699.789:272): avc: denied { send } for
> > saddr=192.168.1.70 src=47248 daddr=66.249.91.18 dest=80 netif=eth0
> > scontext=user_u:system_r:unconfined_t:s0
> > tcontext=system_u:system_r:kernel_t:s0 tclass=packet
> >
> > so the roots of the problem may lie between 2.6.20.4 and 2.6.20.6
> >
> > http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console2.log
>
> Might be related to this:
> http://marc.info/?l=git-commits-head&m=118271540932264&w=2
Interesting, this one was fixed in 2.6.22-rc6, but is neither in 2.6.20
nor in 2.6.21. Michal, could you please try to apply the patch ? I include
it here for your convenience. If it fixes your problem, I can queue it for
next 2.6.20-stable, and forward it to the -stable team for 2.6.21 in case
Greg and Chris plan to release another one.
From: Patrick McHardy <[email protected]>
Date: Sun, 24 Jun 2007 05:58:34 +0000 (-0700)
Subject: [SKBUFF]: Fix incorrect config #ifdef around skb_copy_secmark
X-Git-Tag: v2.6.22~103^2~6
X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=dbbeb2f9917792b989b6269ebfe24257f9aa1618
[SKBUFF]: Fix incorrect config #ifdef around skb_copy_secmark
secmark doesn't depend on CONFIG_NET_SCHED.
Signed-off-by: Patrick McHardy <[email protected]>
Acked-by: James Morris <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
---
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 7c6a34e..8d43ae6 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -434,8 +434,8 @@ struct sk_buff *skb_clone(struct sk_buff *skb, gfp_t gfp_mask)
n->tc_verd = CLR_TC_MUNGED(n->tc_verd);
C(iif);
#endif
- skb_copy_secmark(n, skb);
#endif
+ skb_copy_secmark(n, skb);
C(truesize);
atomic_set(&n->users, 1);
C(head);
Thanks,
Willy
Willy Tarreau pisze:
> On Wed, Aug 22, 2007 at 03:15:14PM -0400, Stephen Smalley wrote:
>> On Wed, 2007-08-22 at 19:50 +0200, Michal Piotrowski wrote:
>>> On 22/08/07, Michal Piotrowski <[email protected]> wrote:
>>>> On 22/08/07, James Morris <[email protected]> wrote:
>>> [snip]
>>>>> The previous problem is theoretically unrelated. It arose via a separate
>>>>> mechanism which can't be used at the same as the one you're seeing now in
>>>>> the logs.
>>>>>
>>>>> So this either looks like a problem which has gone unnoticed and was
>>>>> inadvertently fixed at some point, or is unique to the 2.6.20 stable
>>>>> series.
>>>> Yup, it is very interesting why no one noticed it. Binary search in progress:
>>>> good - 2.6.20.4
>>>> bad - 2.6.20.8
>>> Ok, I narrowed the problem to 2.6.20.7. There are a few net changes
>>> http://eu.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.20.7
>>> any suggestions?
>>>
>>> I also have seen this avc on 2.6.20.6 during reboot
>>>
>>> [ 2333.905944] audit(1187803699.273:271): avc: denied { send } for
>>> saddr=192.168.1.70 src=48591 daddr=72.14.217.189 dest=80 netif=eth0
>>> scontext=user_u:system_r:unconfined_t:s0
>>> tcontext=system_u:system_r:kernel_t:s0 tclass=packet
>>> [ 2334.420598] audit(1187803699.789:272): avc: denied { send } for
>>> saddr=192.168.1.70 src=47248 daddr=66.249.91.18 dest=80 netif=eth0
>>> scontext=user_u:system_r:unconfined_t:s0
>>> tcontext=system_u:system_r:kernel_t:s0 tclass=packet
>>>
>>> so the roots of the problem may lie between 2.6.20.4 and 2.6.20.6
>>>
>>> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console2.log
>> Might be related to this:
>> http://marc.info/?l=git-commits-head&m=118271540932264&w=2
>
> Interesting, this one was fixed in 2.6.22-rc6, but is neither in 2.6.20
> nor in 2.6.21. Michal, could you please try to apply the patch ? I include
> it here for your convenience. If it fixes your problem, I can queue it for
> next 2.6.20-stable, and forward it to the -stable team for 2.6.21 in case
> Greg and Chris plan to release another one.
>
I confirm that this patch fixes the problem.
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
On Thu, Aug 23, 2007 at 01:13:56PM +0200, Michal Piotrowski wrote:
> Willy Tarreau pisze:
> > On Wed, Aug 22, 2007 at 03:15:14PM -0400, Stephen Smalley wrote:
> >> On Wed, 2007-08-22 at 19:50 +0200, Michal Piotrowski wrote:
> >>> On 22/08/07, Michal Piotrowski <[email protected]> wrote:
> >>>> On 22/08/07, James Morris <[email protected]> wrote:
> >>> [snip]
> >>>>> The previous problem is theoretically unrelated. It arose via a separate
> >>>>> mechanism which can't be used at the same as the one you're seeing now in
> >>>>> the logs.
> >>>>>
> >>>>> So this either looks like a problem which has gone unnoticed and was
> >>>>> inadvertently fixed at some point, or is unique to the 2.6.20 stable
> >>>>> series.
> >>>> Yup, it is very interesting why no one noticed it. Binary search in progress:
> >>>> good - 2.6.20.4
> >>>> bad - 2.6.20.8
> >>> Ok, I narrowed the problem to 2.6.20.7. There are a few net changes
> >>> http://eu.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.20.7
> >>> any suggestions?
> >>>
> >>> I also have seen this avc on 2.6.20.6 during reboot
> >>>
> >>> [ 2333.905944] audit(1187803699.273:271): avc: denied { send } for
> >>> saddr=192.168.1.70 src=48591 daddr=72.14.217.189 dest=80 netif=eth0
> >>> scontext=user_u:system_r:unconfined_t:s0
> >>> tcontext=system_u:system_r:kernel_t:s0 tclass=packet
> >>> [ 2334.420598] audit(1187803699.789:272): avc: denied { send } for
> >>> saddr=192.168.1.70 src=47248 daddr=66.249.91.18 dest=80 netif=eth0
> >>> scontext=user_u:system_r:unconfined_t:s0
> >>> tcontext=system_u:system_r:kernel_t:s0 tclass=packet
> >>>
> >>> so the roots of the problem may lie between 2.6.20.4 and 2.6.20.6
> >>>
> >>> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20.17-rc1/console2.log
> >> Might be related to this:
> >> http://marc.info/?l=git-commits-head&m=118271540932264&w=2
> >
> > Interesting, this one was fixed in 2.6.22-rc6, but is neither in 2.6.20
> > nor in 2.6.21. Michal, could you please try to apply the patch ? I include
> > it here for your convenience. If it fixes your problem, I can queue it for
> > next 2.6.20-stable, and forward it to the -stable team for 2.6.21 in case
> > Greg and Chris plan to release another one.
> >
>
> I confirm that this patch fixes the problem.
Perfect, thanks for your fast feedback, it is really appreciated !
I'm queuing it for 2.6.20.18.
Regards,
Willy