1 |
> > Used strace and it seems that PaX is the culpit, could somebody confirm |
2 |
> > this? |
3 |
> |
4 |
> Your understanding of the problem seems backwards. python is probably |
5 |
> the culpit and PaX is only making it obvious that something else has a |
6 |
> fundamental code flaw. |
7 |
> (It bugs me when I see people blame pax & grsec for faulty software) |
8 |
|
9 |
ok, after having looked at the strace, i see a few things only: |
10 |
|
11 |
1. there's a sign of ld.so:make_stack_executable() failing, apparently |
12 |
because /usr/lib/libcrypto.so.0.9.7 is marked with an executable |
13 |
PT_GNU_STACK. i think that's a known false positive (PT_PAX_FLAGS |
14 |
doesn't have emutramp enabled here). |
15 |
|
16 |
2. there's only one mmap request that creates (well, tries to ;-) a |
17 |
writable/executable mapping and that's right after mapping psyco.so. |
18 |
based on the package description ("[it] can massively speed up the |
19 |
execution of any Python code") i bet it does exactly that by generating |
20 |
code at runtime (the website confirms that it does JIT compilation), |
21 |
hence it will not work with non-executable pages. since this is a |
22 |
library you have to disable MPROTECT on the executable that uses it, |
23 |
in this case python. |
24 |
|
25 |
PS: rumen, i think you don't need to bother with those extra logs and |
26 |
straces i asked for in the previous mail, just disable MPROTECT |
27 |
on python and be done with it (i've tested it here). |
28 |
|
29 |
|
30 |
-- |
31 |
gentoo-hardened@g.o mailing list |