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