| 1 |
On 08/01/12 09:08, PaX Team wrote: |
| 2 |
> On 1 Aug 2012 at 8:41, Michael Orlitzky wrote: |
| 3 |
> |
| 4 |
>> Thanks, here are strace -f logs from both the hardened box (where it |
| 5 |
>> fails) and a vanilla gentoo x86 VM (where it works). |
| 6 |
> |
| 7 |
> mmap2(NULL, 307200000, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = -1 ENOMEM (Cannot allocate memory) |
| 8 |
> |
| 9 |
> this can fail for several reasons, not enough RAM (depends on how overcommit is set), |
| 10 |
> not enough address space (hardened/PIE and ASLR together change how big the holes in |
| 11 |
> the address space end up, SEGMEXEC halves the address space), etc. |
| 12 |
> |
| 13 |
> |
| 14 |
|
| 15 |
Hmm.. I think this indirectly solves the problem. I've got, |
| 16 |
|
| 17 |
# cat /etc/security/limits.d/50-clamd.conf |
| 18 |
#<domain> <type> <item> <value> |
| 19 |
clamav - stack 512000 |
| 20 |
|
| 21 |
But it isn't taking effect: |
| 22 |
|
| 23 |
# cat /proc/25394/limits | grep stack |
| 24 |
Max stack size 307200000 307200000 bytes |
| 25 |
|
| 26 |
So, clamd is likely running out of stack just like the test program. I |
| 27 |
can probably figure that one out. |
| 28 |
|
| 29 |
But, I'd ruled out the stack size limitation because resource oversteps |
| 30 |
are supposed to be reported: |
| 31 |
|
| 32 |
# cat /proc/config.gz | gunzip | grep GRKERNSEC_RESLOG |
| 33 |
CONFIG_GRKERNSEC_RESLOG=y |
| 34 |
|
| 35 |
I've got nothing logged, even after the failures. |
Archives