| Summary: | sys-kernel/hardened-sources-2.6.36-r7: NFS and Samba server "broken" | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | El Goretto <el.goretto> |
| Component: | Hardened | Assignee: | The Gentoo Linux Hardened Kernel Team (OBSOLETE) <hardened-kernel+disabled> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | hardened, pageexec, spender |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | kernel 2.6.36-hardened-r7 config | ||
|
Description
El Goretto
2010-12-31 13:43:01 UTC
Created attachment 258529 [details]
kernel 2.6.36-hardened-r7 config
(In reply to comment #1) > Created an attachment (id=258529) [details] > kernel 2.6.36-hardened-r7 config > Thanks for the report. I don't have some of your hardware so I have to ask you to try a few things: 1) Do a diff between the configs for 2.6.36-hardened-r2 and 2.6.36-hardened-r7 and make sure they are the same. If not post the diff. 2) Using your 2.6.36-hardened-r7, turn off all GRSEC and PaX options and see if the problem clears. If it doesn't then try vanilla 2.6.36.2 with the same config, except GRSEC/PaX obviously. Report your results I have a suspicion it may be due to the changes to the R8169 driver that comes from vanilla and its interaction with GRSEC/PaX. In the mean time, 2.6.36-r2 is secure provided you don't configure ECONET which you almost certainly don't need. Hi Anthony, here we go:
1) Do a diff between the configs for 2.6.36-hardened-r2 and 2.6.36-hardened-r7
and make sure they are the same. If not post the diff.
3,4c3,4
< # Linux kernel version: 2.6.36-hardened-r2
< # Wed Dec 22 15:31:51 2010
---
> # Linux kernel version: 2.6.36-hardened-r7
> # Tue Dec 28 11:15:22 2010
345d344
< CONFIG_CC_STACKPROTECTOR=y
682d680
< # CONFIG_ECONET is not set
I checked CC_STACKPROTECTOR and why it isn't enabled anymore:
"Depends on: X86_64 [=n] || !PAX_MEMORY_UDEREF [=y]"
Ok then, none of these conditions is met on my box :)
2) Using your 2.6.36-hardened-r7, turn off all GRSEC and PaX options and see if
the problem clears. If it doesn't then try vanilla 2.6.36.2 with the same
config, except GRSEC/PaX obviously. Report your results
Booted 2.6.36-hardened-r7 without grsec nor pax, and NFS "works" again (can't test samba right now. If you want I may try it later).
(In reply to comment #3) > Hi Anthony, here we go: > > 1) Do a diff between the configs for 2.6.36-hardened-r2 and 2.6.36-hardened-r7 > and make sure they are the same. If not post the diff. > > 3,4c3,4 > < # Linux kernel version: 2.6.36-hardened-r2 > < # Wed Dec 22 15:31:51 2010 > --- > > # Linux kernel version: 2.6.36-hardened-r7 > > # Tue Dec 28 11:15:22 2010 > 345d344 > < CONFIG_CC_STACKPROTECTOR=y > 682d680 > < # CONFIG_ECONET is not set > > I checked CC_STACKPROTECTOR and why it isn't enabled anymore: > "Depends on: X86_64 [=n] || !PAX_MEMORY_UDEREF [=y]" > Ok then, none of these conditions is met on my box :) > > > 2) Using your 2.6.36-hardened-r7, turn off all GRSEC and PaX options and see if > the problem clears. If it doesn't then try vanilla 2.6.36.2 with the same > config, except GRSEC/PaX obviously. Report your results > > Booted 2.6.36-hardened-r7 without grsec nor pax, and NFS "works" again (can't > test samba right now. If you want I may try it later). > Okay it a hardened issue. I thought it might be hardware related because I can't reproduce it here, and the major difference between our config files is hardware. Something changed between 36-r2 which was based on grsecurity-2.2.0-2.6.36-201011151726 and 36-r7 based on grsecurity-2.2.1-2.6.36.2-201012221906 I'll poke upstream see if they have a clue. I will be adding 36-r8 soon, and you may want to try that, but I don't see any obvious changes that would address this. Tried 2.6.36-hardened-r8 with the very same .config than -r7... and "it works". Ahem. Well, good for me then, but I'm unable to identify what has changed. I'll test it further and report if a problem arise on r8. (In reply to comment #5) > Tried 2.6.36-hardened-r8 with the very same .config than -r7... and "it works". > Ahem. Well, good for me then, but I'm unable to identify what has changed. > I'll test it further and report if a problem arise on r8. > Please keep me up to date. 2.6.36-r8 and 2.6.32-r33 have shown no issues so far and are the next candidates for stabilization. I'll close this bug once they go stable. (In reply to comment #5) > Tried 2.6.36-hardened-r8 with the very same .config than -r7... and "it works". > Ahem. Well, good for me then, but I'm unable to identify what has changed. there was a small issue with a recent change in UDEREF/i386 where i forgot to update the IP checksum code that works directly on userland, so any kernel networking facility that relied on it was broken. (In reply to comment #7) > (In reply to comment #5) > > Tried 2.6.36-hardened-r8 with the very same .config than -r7... and "it works". > > Ahem. Well, good for me then, but I'm unable to identify what has changed. > > there was a small issue with a recent change in UDEREF/i386 where i forgot to > update the IP checksum code that works directly on userland, so any kernel > networking facility that relied on it was broken. Thank you very much for this clarification. 2.6.36-r9 and 2.6.32-r34 are now in the tree and include the fix. Closing. |
