| 1 |
On 9 Dec 2005 at 2:49, JM wrote: |
| 2 |
> Linux praisenet 2.6.13-rsbac-rsbac #2 Mon Dec 5 17:06:35 CET 2005 i686 Pentium |
| 3 |
> III (Katmai) GenuineIntel GNU/Linux |
| 4 |
|
| 5 |
as far as PaX is concerned, 2.6.14 is the last 'supported' version, |
| 6 |
as in, i fix stuff only in there, and i'm sure i did do so since the |
| 7 |
2.6.13 port was abandoned. so if you can give that a try and reproduce |
| 8 |
this, it'll help confirm/eliminate PaX bug at least. |
| 9 |
|
| 10 |
> I have Pax and some RSBAC modules compiled in, if requested I may attach my |
| 11 |
> configuration. |
| 12 |
> Should I send someone else this log too? |
| 13 |
|
| 14 |
Amon Ott probably would be interested as well. |
| 15 |
|
| 16 |
> Dec 9 02:35:01 hostname PREEMPT |
| 17 |
|
| 18 |
can you try without preempt? i never really audited PaX for such use, |
| 19 |
even if i think most of the code is not sensitive to it, it's better |
| 20 |
to leave it off. |
| 21 |
|
| 22 |
> Dec 9 02:35:01 hostname Call Trace: |
| 23 |
> Dec 9 02:35:01 hostname Code: 65 78 00 5f 5f 64 65 76 5f 67 65 74 5f 62 79 |
| 24 |
> 5f 6e 61 6d 65 00 5f 5f 64 65 76 5f 72 65 6d 6f 76 65 5f 70 61 63 6b 00 5f 5f |
| 25 |
> 73 6b <62> 5f 6c 69 6e 65 61 72 69 7a 65 00 64 65 76 5f 61 64 64 5f 70 |
| 26 |
|
| 27 |
this points to something royally hosed. the above 'code' resolves to |
| 28 |
a plain ascii string, eip fell into the middle of '__skb_linearize', |
| 29 |
hardly valid machine code ;-). but short of a valid stacktrace, it's |
| 30 |
hard to tell what the kernel was doing. maybe if you disabled module |
| 31 |
support and enabled KERNEXEC you'd get a better stacktrace, but that's |
| 32 |
just a guess. if you can reproduce it reliably, you could also just |
| 33 |
try PaX (on 2.6.14 as well) and RSBAC alone. |
| 34 |
|
| 35 |
-- |
| 36 |
gentoo-hardened@g.o mailing list |
Archives