| 1 |
On 30 Nov 2007 at 2:17, Alex Efros wrote: |
| 2 |
|
| 3 |
> Latests "stable" in portage now is 2.6.22-hardened-r8. I remember |
| 4 |
> discussion in this maillist about a week ago, with some hardened-related |
| 5 |
> bug reported in .22 and .23 kernels. I'm not sure is that fix already |
| 6 |
> included in .22-r8, that's why I doesn't upgrade yet. Do you know which |
| 7 |
> .22 or .23 ebuilds already contain your fix for that bug? |
| 8 |
|
| 9 |
.22 won't be fixed, we're working on .23 only. latest grsec has |
| 10 |
all the necessary fixes, i don't know if there's an ebuild with |
| 11 |
that yet though. |
| 12 |
|
| 13 |
> > thanks, i reproduced it with that site now. it seems that (probably) |
| 14 |
> > flash resorts to some runtime code generation, therefore chpax/paxctl |
| 15 |
> > -m on firefox and that opera wrapper is enough to get it to work, no |
| 16 |
> > need to disable non-exec pages altogether. not that it's a good solution |
| 17 |
> |
| 18 |
> Yep, -m is what I tried first, but it won't help, so I tried another flags. |
| 19 |
|
| 20 |
what problems did you have with -m alone? i know it worked here... |
| 21 |
|
| 22 |
> Just to be sure I understand you correctly, this issue is in flashplayer |
| 23 |
> plugin itself, and only Adobe can fix it (which is unlikely, I think). |
| 24 |
|
| 25 |
yes it seems so (it'd take a whole lot more debugging to pin down the |
| 26 |
exact code that generated the code at runtime, but given that it occurs |
| 27 |
with adobe's flashplayer, it's a safe but who the culprit is). |
| 28 |
|
| 29 |
> So only possible choice is relax PaX for browsers :( or just don't use |
| 30 |
> flash applets which won't work without relaxing PaX. Correct? |
| 31 |
|
| 32 |
or as a third option, use another flash player, although your particular |
| 33 |
page doesn't seem to work with anything else i tried but adobe's. |
| 34 |
|
| 35 |
-- |
| 36 |
gentoo-hardened@g.o mailing list |
Archives