[gentoo-hardened] what RLIMIT_STACK mean?

[gentoo-hardened] what RLIMIT_STACK mean?

[Alex Efros]

Hi!

Can you please explain to me what these records in my logs mean?

    2008-09-27_11:35:55.93144 kern.alert: grsec: From 78.53.3.223: denied
    resource overstep by requesting 180883456 for RLIMIT_STACK against limit
    8388608 for /bin/cat[cat:10111] uid/euid:81/81 gid/egid:81/81, parent
    /usr/sbin/apache2[apache2:21930] uid/euid:81/81 gid/egid:81/81

    2008-09-27_12:08:17.12634 kern.alert: grsec: denied resource overstep by
    requesting 187367424 for RLIMIT_STACK against limit 8388608 for
    /var/qmail/bin/qmail-local[qmail-local:22538] uid/euid:1000/1000
    gid/egid:100/100, parent /var/qmail/bin/qmail-local[qmail-local:22535]
    uid/euid:1000/1000 gid/egid:100/100

For example, first record may be result of malicious http request sent
from 78.53.3.223 to my apache... but I've no idea why /bin/cat was called
(I don't aware about cgi scripts on my server which will call /bin/cat)
and what went wrong with it. I'm not sure how this guess is correct...

Second is even more strange, because qmail-local was called by
qmail-local, there no "From IP" part in this record, so it looks like some
internal error on my server... but I never notice any troubles with qmail,
mail works ok and there no error in qmail log. Actually, here are records
from qmail log related to same time:

    2008-09-27_12:08:17.07092 new msg 662104
    2008-09-27_12:08:17.07093 info msg 662104: bytes 2912 from
    <gentoo-hardened+bounces-2147-powerman=powerman.asdfgroup.com@lists.gentoo.org>
    qp 22534 uid 201
    2008-09-27_12:08:17.07403 starting delivery 5800: msg 662104 to local
    powerman@powerman.asdfgroup.com
    2008-09-27_12:08:17.07404 status: local 1/10 remote 0/20
    2008-09-27_12:08:17.14903 delivery 5800: success: did_1+0+0/did_0+0+2/
    2008-09-27_12:08:17.14905 status: local 0/10 remote 0/20
    2008-09-27_12:08:17.14905 end msg 662104

As you see, it was incoming email from this maillist, which was delivered
without issues... so it wasn't some malicious spam message which trying to
crash my qmail. I've no idea why grsec complain in logs about it.

I've a lot of such records - about 5 new records every hour in average.
I've checked all combinations of "for /..., parent /...":

# grep RLIMIT_STACK /var/log/kernel/all/{@*,current} |
perl -pe 's/.* (for \/[^:]*).* (parent \/[^:]*).*/$1] $2]/' | sort | uniq -c
    303 for /bin/bash[sh] parent /bin/bash[sh]
    277 for /bin/cat[cat] parent /usr/sbin/apache2[apache2]
     17 for /bin/su[su] parent /usr/bin/runsv[runsv]
      1 for /[chpst] parent /bin/bash[sh]
      1 for /[egrep] parent /bin/bash[sh]
      1 for /[ifconfig] parent /bin/bash[sh]
      8 for /[sh] parent /usr/sbin/crond[crond]
    341 for /var/qmail/bin/qmail-local[qmail-local] parent /var/qmail/bin/qmail-local[qmail-local]

-- 
			WBR, Alex.

Re: [gentoo-hardened] what RLIMIT_STACK mean?

[Alex Efros]

Hi!

On Sat, Sep 27, 2008 at 03:42:33PM +0300, Alex Efros wrote:
> Can you please explain to me what these records in my logs mean?
> 
>     2008-09-27_11:35:55.93144 kern.alert: grsec: From 78.53.3.223: denied
>     resource overstep by requesting 180883456 for RLIMIT_STACK against limit
>     8388608 for /bin/cat[cat:10111] uid/euid:81/81 gid/egid:81/81, parent
>     /usr/sbin/apache2[apache2:21930] uid/euid:81/81 gid/egid:81/81
> 
>     2008-09-27_12:08:17.12634 kern.alert: grsec: denied resource overstep by
>     requesting 187367424 for RLIMIT_STACK against limit 8388608 for
>     /var/qmail/bin/qmail-local[qmail-local:22538] uid/euid:1000/1000
>     gid/egid:100/100, parent /var/qmail/bin/qmail-local[qmail-local:22535]
>     uid/euid:1000/1000 gid/egid:100/100

Is my question too complex and nobody know the answer (or even guesses),
or it's too stupid and everybody wait until I try google (I've tried it
already, without success)?

Is last days I also notice new alert type in log:

	2008-09-29_15:14:14.47478 kern.alert: grsec: From 78.129.196.12: denied
	resource overstep by requesting 227184640 for RLIMIT_AS against
	limit 16000000 for /var/qmail/bin/qmail-smtpd[qmail-smtpd:6545]
	uid/euid:201/201 gid/egid:200/200, parent
	/usr/bin/tcpserver[tcpserver:17002] uid/euid:201/201
	gid/egid:200/200

This type of alerts arise after I added simple perl script, between
tcpserver and qmail-smtpd, which do greylisting. And, again, these alerts
doesn't affect server - I mean, everything works fine, no mail lost, etc.

-- 
			WBR, Alex.

Re: [gentoo-hardened] what RLIMIT_STACK mean?

[Javier Martínez]

I think it's not a good idea to do what you have done, people answers
questions if they know the answer and they want to do it (and have
time to do so). Please think that you didn't pay anybody to demand
nothing.

I don't use grsecurity but it seems that cat needs to growth their
stack over the hard limit imposed (look for "ulimit -a") and it's not
permitted (to avoid DOS maybe), look for some grsec resource that
impose limits to your stack and others (as open files, cpu time...),
if it's related to grsec (as it seems to be) you will need to make
this limit bigger.



2008/9/29 Alex Efros <powerman@powerman.asdfgroup.com>:
> Hi!
>
> On Sat, Sep 27, 2008 at 03:42:33PM +0300, Alex Efros wrote:
>> Can you please explain to me what these records in my logs mean?
>>
>>     2008-09-27_11:35:55.93144 kern.alert: grsec: From 78.53.3.223: denied
>>     resource overstep by requesting 180883456 for RLIMIT_STACK against limit
>>     8388608 for /bin/cat[cat:10111] uid/euid:81/81 gid/egid:81/81, parent
>>     /usr/sbin/apache2[apache2:21930] uid/euid:81/81 gid/egid:81/81
>>
>>     2008-09-27_12:08:17.12634 kern.alert: grsec: denied resource overstep by
>>     requesting 187367424 for RLIMIT_STACK against limit 8388608 for
>>     /var/qmail/bin/qmail-local[qmail-local:22538] uid/euid:1000/1000
>>     gid/egid:100/100, parent /var/qmail/bin/qmail-local[qmail-local:22535]
>>     uid/euid:1000/1000 gid/egid:100/100
>
> Is my question too complex and nobody know the answer (or even guesses),
> or it's too stupid and everybody wait until I try google (I've tried it
> already, without success)?
>
> Is last days I also notice new alert type in log:
>
>        2008-09-29_15:14:14.47478 kern.alert: grsec: From 78.129.196.12: denied
>        resource overstep by requesting 227184640 for RLIMIT_AS against
>        limit 16000000 for /var/qmail/bin/qmail-smtpd[qmail-smtpd:6545]
>        uid/euid:201/201 gid/egid:200/200, parent
>        /usr/bin/tcpserver[tcpserver:17002] uid/euid:201/201
>        gid/egid:200/200
>
> This type of alerts arise after I added simple perl script, between
> tcpserver and qmail-smtpd, which do greylisting. And, again, these alerts
> doesn't affect server - I mean, everything works fine, no mail lost, etc.
>
> --
>                        WBR, Alex.
>
>

Re: [gentoo-hardened] what RLIMIT_STACK mean?

[Alex Efros]

Hi!

On Mon, Sep 29, 2008 at 05:46:28PM +0200, Javier Mart?nez wrote:
> I think it's not a good idea to do what you have done, people answers
> questions if they know the answer and they want to do it (and have
> time to do so). Please think that you didn't pay anybody to demand
> nothing.

I understand, but I don't think something was wrong in this case.

At first, I don't just "demand answers", I also spend my own time
contributing to community - answer questions in different maillists,
submit to bugzilla, etc. And have enough free soft and documentation on my
home website.

At second, I don't just "refresh" that thread, but add new information
about topic which may be important for people who trying to find answer or
for people who will search this maillist later looking for same issue.

> I don't use grsecurity but it seems that cat needs to growth their
> stack over the hard limit imposed (look for "ulimit -a") and it's not
> permitted (to avoid DOS maybe), look for some grsec resource that
> impose limits to your stack and others (as open files, cpu time...),
> if it's related to grsec (as it seems to be) you will need to make
> this limit bigger.

Sorry, but this isn't an answer I looking for. I know several ways how to
silence it - for example, I can just filter these records from logs.
My questions isn't "how to fix it", but "what is it" instead. Before
fixing something it's always good idea to understand what and why you're
fixing first.

I don't understand these errors, and that's my problem.
If it's just "ulimit" thing, then it mean kernel should KILL these
processes. But this isn't happens - or there should be other noticeable
issues like undelivered mail or so, which I don't notice for now.

-- 
			WBR, Alex.

Re: [gentoo-hardened] what RLIMIT_STACK mean?

[Javier Martínez]

As I said it seems to be a problem with the rlimits, maybe
CAP_SYS_RESOURCE privilege is not granted to the binaries affected, or
you have problems with ulimit as I said. You can strace the binary to
see what it does and the error code, and with a more deep knowledge of
the problem to solve it.

2008/9/29 Alex Efros <powerman@powerman.asdfgroup.com>:
> Hi!
>
> On Mon, Sep 29, 2008 at 05:46:28PM +0200, Javier Mart?nez wrote:
>> I think it's not a good idea to do what you have done, people answers
>> questions if they know the answer and they want to do it (and have
>> time to do so). Please think that you didn't pay anybody to demand
>> nothing.
>
> I understand, but I don't think something was wrong in this case.
>
> At first, I don't just "demand answers", I also spend my own time
> contributing to community - answer questions in different maillists,
> submit to bugzilla, etc. And have enough free soft and documentation on my
> home website.
>
> At second, I don't just "refresh" that thread, but add new information
> about topic which may be important for people who trying to find answer or
> for people who will search this maillist later looking for same issue.
>
>> I don't use grsecurity but it seems that cat needs to growth their
>> stack over the hard limit imposed (look for "ulimit -a") and it's not
>> permitted (to avoid DOS maybe), look for some grsec resource that
>> impose limits to your stack and others (as open files, cpu time...),
>> if it's related to grsec (as it seems to be) you will need to make
>> this limit bigger.
>
> Sorry, but this isn't an answer I looking for. I know several ways how to
> silence it - for example, I can just filter these records from logs.
> My questions isn't "how to fix it", but "what is it" instead. Before
> fixing something it's always good idea to understand what and why you're
> fixing first.
>
> I don't understand these errors, and that's my problem.
> If it's just "ulimit" thing, then it mean kernel should KILL these
> processes. But this isn't happens - or there should be other noticeable
> issues like undelivered mail or so, which I don't notice for now.
>
> --
>                        WBR, Alex.
>
>

Re: [gentoo-hardened] what RLIMIT_STACK mean?

[Javier Martínez]

PD: to see why the stack growth so much you can only pass  gdb to the
binary itself, as you can suppose I can't know why it happens to you.

2008/9/29 Javier Martínez <tazok.id0@gmail.com>:
> As I said it seems to be a problem with the rlimits, maybe
> CAP_SYS_RESOURCE privilege is not granted to the binaries affected, or
> you have problems with ulimit as I said. You can strace the binary to
> see what it does and the error code, and with a more deep knowledge of
> the problem to solve it.
>
> 2008/9/29 Alex Efros <powerman@powerman.asdfgroup.com>:
>> Hi!
>>
>> On Mon, Sep 29, 2008 at 05:46:28PM +0200, Javier Mart?nez wrote:
>>> I think it's not a good idea to do what you have done, people answers
>>> questions if they know the answer and they want to do it (and have
>>> time to do so). Please think that you didn't pay anybody to demand
>>> nothing.
>>
>> I understand, but I don't think something was wrong in this case.
>>
>> At first, I don't just "demand answers", I also spend my own time
>> contributing to community - answer questions in different maillists,
>> submit to bugzilla, etc. And have enough free soft and documentation on my
>> home website.
>>
>> At second, I don't just "refresh" that thread, but add new information
>> about topic which may be important for people who trying to find answer or
>> for people who will search this maillist later looking for same issue.
>>
>>> I don't use grsecurity but it seems that cat needs to growth their
>>> stack over the hard limit imposed (look for "ulimit -a") and it's not
>>> permitted (to avoid DOS maybe), look for some grsec resource that
>>> impose limits to your stack and others (as open files, cpu time...),
>>> if it's related to grsec (as it seems to be) you will need to make
>>> this limit bigger.
>>
>> Sorry, but this isn't an answer I looking for. I know several ways how to
>> silence it - for example, I can just filter these records from logs.
>> My questions isn't "how to fix it", but "what is it" instead. Before
>> fixing something it's always good idea to understand what and why you're
>> fixing first.
>>
>> I don't understand these errors, and that's my problem.
>> If it's just "ulimit" thing, then it mean kernel should KILL these
>> processes. But this isn't happens - or there should be other noticeable
>> issues like undelivered mail or so, which I don't notice for now.
>>
>> --
>>                        WBR, Alex.
>>
>>
>

Re: [gentoo-hardened] what RLIMIT_STACK mean?

[Alex Efros]

[-- Attachment #1: Type: text/plain, Size: 1370 bytes --]

Hi!

On Mon, Sep 29, 2008 at 06:10:00PM +0200, Javier Mart?nez wrote:
> PD: to see why the stack growth so much you can only pass  gdb to the
> binary itself, as you can suppose I can't know why it happens to you.

While trying to strace I got smaller example which has same effect - it
generate grsec alert - just like qmail-smtpd, and that happens randomly,
i.e. not on each execution - just like qmail-smtpd.

Below is two executions,

    $ perl -e 'system("strace -p $$ -o pwd.strace.$$ &"); sleep 1; exec @ARGV' /bin/pwd
    Process 4440 attached - interrupt to quit
    /home/powerman
    Process 4440 detached

    $ perl -e 'system("strace -p $$ -o pwd.strace.$$ &"); sleep 1; exec @ARGV' /bin/pwd
    Process 4495 attached - interrupt to quit
    /home/powerman
    Process 4495 detached

and second have generated grsec alert:

    2008-09-29_16:16:39.16191 kern.alert: grsec: denied resource overstep
    by requesting 35188736 for RLIMIT_STACK against limit 8388608 for
    /bin/pwd[pwd:4495] uid/euid:1000/1000 gid/egid:100/100, parent
    /bin/bash[bash:28139] uid/euid:1000/1000 gid/egid:100/100

I've attached both strace logs, but, as far as I see, there nothing
significant there. If you give me an example how to gather important
information using gdb - I'll do it too (I'm Perl programmer and sysadmin
and not familiar with gdb).

-- 
			WBR, Alex.

[-- Attachment #2: pwd.strace.4440 --]
[-- Type: text/plain, Size: 2614 bytes --]

restart_syscall(<... resuming interrupted call ...>) = 0
time(NULL)                              = 1222704996
rt_sigaction(SIGFPE, {SIG_DFL}, {SIG_IGN}, 8) = 0
execve("/bin/pwd", ["/bin/pwd"], [/* 57 vars */]) = 0
brk(0)                                  = 0x105f1114
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=73219, ...}) = 0
mmap2(NULL, 73219, PROT_READ, MAP_PRIVATE, 3, 0) = 0x543f9000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@a\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1249516, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x543f8000
mmap2(NULL, 1255696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x542c5000
mmap2(0x543f2000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12d) = 0x543f2000
mmap2(0x543f5000, 10512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x543f5000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x542c4000
set_thread_area({entry_number:-1 -> 6, base_addr:0x542c46c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
open("/dev/urandom", O_RDONLY)          = 3
read(3, "\263\205\37\245", 4)           = 4
close(3)                                = 0
mprotect(0x543f2000, 8192, PROT_READ)   = 0
mprotect(0x105ec000, 4096, PROT_READ)   = 0
mprotect(0x54426000, 4096, PROT_READ)   = 0
munmap(0x543f9000, 73219)               = 0
brk(0)                                  = 0x105f1114
brk(0x10612114)                         = 0x10612114
brk(0x10613000)                         = 0x10613000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2684224, ...}) = 0
mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0x540c4000
close(3)                                = 0
getcwd("/home/powerman", 4096)          = 15
brk(0x10612000)                         = 0x10612000
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 8), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x5440a000
write(1, "/home/powerman\n", 15)        = 15
close(1)                                = 0
munmap(0x5440a000, 4096)                = 0
close(2)                                = 0
exit_group(0)                           = ?

[-- Attachment #3: pwd.strace.4495 --]
[-- Type: text/plain, Size: 2614 bytes --]

restart_syscall(<... resuming interrupted call ...>) = 0
time(NULL)                              = 1222704999
rt_sigaction(SIGFPE, {SIG_DFL}, {SIG_IGN}, 8) = 0
execve("/bin/pwd", ["/bin/pwd"], [/* 57 vars */]) = 0
brk(0)                                  = 0x13801194
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=73219, ...}) = 0
mmap2(NULL, 73219, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4a691000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@a\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1249516, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4a690000
mmap2(NULL, 1255696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4a55d000
mmap2(0x4a68a000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12d) = 0x4a68a000
mmap2(0x4a68d000, 10512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4a68d000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4a55c000
set_thread_area({entry_number:-1 -> 6, base_addr:0x4a55c6c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
open("/dev/urandom", O_RDONLY)          = 3
read(3, "\347s\367u", 4)                = 4
close(3)                                = 0
mprotect(0x4a68a000, 8192, PROT_READ)   = 0
mprotect(0x137f1000, 4096, PROT_READ)   = 0
mprotect(0x4a6be000, 4096, PROT_READ)   = 0
munmap(0x4a691000, 73219)               = 0
brk(0)                                  = 0x13801194
brk(0x13822194)                         = 0x13822194
brk(0x13823000)                         = 0x13823000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2684224, ...}) = 0
mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4a35c000
close(3)                                = 0
getcwd("/home/powerman", 4096)          = 15
brk(0x13822000)                         = 0x13822000
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 8), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4a6a2000
write(1, "/home/powerman\n", 15)        = 15
close(1)                                = 0
munmap(0x4a6a2000, 4096)                = 0
close(2)                                = 0
exit_group(0)                           = ?

Re: [gentoo-hardened] what RLIMIT_STACK mean?

[pageexec]

On 29 Sep 2008 at 18:21, Alex Efros wrote:

> Is my question too complex and nobody know the answer (or even guesses),
> or it's too stupid and everybody wait until I try google (I've tried it
> already, without success)?

maybe it's because of what you said:

> I've no idea why grsec complain in logs about it.

at this point it's clear that you didn't quite read the description of
GRKERNSEC_RESLOG which is what you've apparently enabled. in short, grsec
is doing what you asked it to do: log various resource overstep events.

why those events occured is another question and each case needs its own
investigation. for example overstepping the default 8MB stack limit by
180MB sounds like a memory corruption problem or something trying to pass
an inordinate amount of data on the stack (say, in the environment).
whether that was because of e.g., a bug in a script on your server or an
exploit attempt is hard to tell after the fact. also the AS limit overstep
is a known issue, qmail tries to be smart and fails to estimate its own
memory needs.

Re: [gentoo-hardened] what RLIMIT_STACK mean?

[Alex Efros]

Hi!

On Mon, Sep 29, 2008 at 06:46:18PM +0200, pageexec@freemail.hu wrote:
> maybe it's because of what you said:
> > I've no idea why grsec complain in logs about it.
> at this point it's clear that you didn't quite read the description of
> GRKERNSEC_RESLOG which is what you've apparently enabled. in short, grsec
> is doing what you asked it to do: log various resource overstep events.

Not really. :) I know I enabled this item, and I understand what it does.
The question is exactly "what's wrong with qmail-smtpd, why it hit
resource limits?".

> why those events occured is another question and each case needs its own
> investigation. for example overstepping the default 8MB stack limit by
> 180MB sounds like a memory corruption problem or something trying to pass
> an inordinate amount of data on the stack (say, in the environment).
> whether that was because of e.g., a bug in a script on your server or an
> exploit attempt is hard to tell after the fact. also the AS limit overstep
> is a known issue, qmail tries to be smart and fails to estimate its own
> memory needs.
 
Now I've smaller example. I've executed this command 10 times:
    perl -e 'exec "/bin/pwd"'
and got 5 records in logs, listed below.
Executing just:
    /bin/pwd
or
    bash -c 'exec /bin/pwd'
many times doesn't result in grsec alerts.
If you wanna say "it's because of perl", I'd like to remind you - there
was no perl scripts between tcpserver and qmail-smtpd before, the command
looks this way:
    /usr/bin/tcpserver -p -v -R -x /etc/tcprules.d/tcp.qmail-smtp.cdb \
	-c 40 -u 201 -g 200 0.0.0.0 smtp /var/qmail/bin/qmail-smtpd

Didn't you think it's good idea to trace this issue? It may be a bug in
grsec... anyway, usual hardened system shouldn't produce such a warnings
in logs just because somebody call exec() from perl script or use qmail.

2008-09-29_16:49:11.85806 kern.alert: grsec: denied resource overstep by requesting 110424064 for RLIMIT_STACK against limit 8388608 for /bin/pwd[pwd:18143] uid/euid:1000/1000 gid/egid:100/100, parent /bin/bash[bash:28139] uid/euid:1000/1000 gid/egid:100/100
2008-09-29_16:49:17.16897 kern.alert: grsec: denied resource overstep by requesting 124620800 for RLIMIT_STACK against limit 8388608 for /bin/pwd[pwd:18250] uid/euid:1000/1000 gid/egid:100/100, parent /bin/bash[bash:28139] uid/euid:1000/1000 gid/egid:100/100
2008-09-29_16:49:19.20874 kern.alert: grsec: denied resource overstep by requesting 137330688 for RLIMIT_STACK against limit 8388608 for /bin/pwd[pwd:18300] uid/euid:1000/1000 gid/egid:100/100, parent /bin/bash[bash:28139] uid/euid:1000/1000 gid/egid:100/100
2008-09-29_16:49:21.16078 kern.alert: grsec: denied resource overstep by requesting 187035648 for RLIMIT_STACK against limit 8388608 for /bin/pwd[pwd:18345] uid/euid:1000/1000 gid/egid:100/100, parent /bin/bash[bash:28139] uid/euid:1000/1000 gid/egid:100/100
2008-09-29_16:49:23.64000 kern.alert: grsec: denied resource overstep by requesting 146747392 for RLIMIT_STACK against limit 8388608 for /bin/pwd[pwd:18398] uid/euid:1000/1000 gid/egid:100/100, parent /bin/bash[bash:28139] uid/euid:1000/1000 gid/egid:100/100

-- 
			WBR, Alex.

Re: [gentoo-hardened] what RLIMIT_STACK mean?

[Adam James]

On Mon, 29 Sep 2008 19:57:02 +0300
Alex Efros <powerman@powerman.asdfgroup.com> wrote:

> > why those events occured is another question and each case needs
> > its own investigation. for example overstepping the default 8MB
> > stack limit by 180MB sounds like a memory corruption problem or
> > something trying to pass an inordinate amount of data on the stack
> > (say, in the environment). whether that was because of e.g., a bug
> > in a script on your server or an exploit attempt is hard to tell
> > after the fact. also the AS limit overstep is a known issue, qmail
> > tries to be smart and fails to estimate its own memory needs.
>  
> Now I've smaller example. I've executed this command 10 times:
>     perl -e 'exec "/bin/pwd"'
> and got 5 records in logs, listed below.
> Executing just:
>     /bin/pwd
> or
>     bash -c 'exec /bin/pwd'
> many times doesn't result in grsec alerts.
> If you wanna say "it's because of perl", I'd like to remind you -
> there was no perl scripts between tcpserver and qmail-smtpd before,
> the command looks this way:
>     /usr/bin/tcpserver -p -v -R -x /etc/tcprules.d/tcp.qmail-smtp.cdb
> \ -c 40 -u 201 -g 200 0.0.0.0 smtp /var/qmail/bin/qmail-smtpd
> 
> Didn't you think it's good idea to trace this issue? It may be a bug
> in grsec... anyway, usual hardened system shouldn't produce such a
> warnings in logs just because somebody call exec() from perl script
> or use qmail.

What's the output of `strace perl -e 'exec "/bin/pwd"' 2>&1 \
|grep -i rlimit`?

Also try invoking perl with `env -i` to rule out any environment issues.

--atj

Re: [gentoo-hardened] what RLIMIT_STACK mean?

[Alex Efros]

Hi!

On Tue, Sep 30, 2008 at 12:29:09AM +0100, Adam James wrote:
> What's the output of `strace perl -e 'exec "/bin/pwd"' 2>&1 \
> |grep -i rlimit`?
> 
> Also try invoking perl with `env -i` to rule out any environment issues.

Results are same, with and without `env -i`:

$ env -i strace /usr/bin/perl -e 'exec "/bin/pwd"' 2>&1 | grep -i rlimit
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0

2008-09-30_00:02:32.77418 kern.alert: grsec: denied resource overstep by requesting 146518016 for RLIMIT_STACK against limit 8388608 for /bin/pwd[pwd:5451] uid/euid:1000/1000 gid/egid:100/100, parent /usr/bin/strace[strace:5449] uid/euid:1000/1000 gid/egid:100/100

-- 
			WBR, Alex.

Re: [gentoo-hardened] what RLIMIT_STACK mean?

[pageexec]

On 29 Sep 2008 at 19:57, Alex Efros wrote:

> Didn't you think it's good idea to trace this issue? It may be a bug in
> grsec... anyway, usual hardened system shouldn't produce such a warnings
> in logs just because somebody call exec() from perl script or use qmail.

sorry, i was busy with everything, didn't have time to look into this. now
that i did, i don't quite get what happens here. thing is, if RLIMIT_STACK
is overstepped, the given process should get a segfault on all execution
paths that i checked yet it clearly hasn't happened according to the strace.
so that leaves one option open, some bug/misreporting by grsec (or maybe PaX?)
but then looking at the code, i don't see how that would happen either... can
you tell me which kernel this happened on (or more precisely, which grsec
version it was) and whether you can still reproduce it with the latest grsec
(or PaX) test patch?

Re: [gentoo-hardened] what RLIMIT_STACK mean?

[Alex Efros]

Hi!

On Sat, Nov 08, 2008 at 11:13:47PM +0200, pageexec@freemail.hu wrote:
> is overstepped, the given process should get a segfault on all execution
> paths that i checked yet it clearly hasn't happened according to the strace.
yeah
> so that leaves one option open, some bug/misreporting by grsec (or maybe PaX?)
> but then looking at the code, i don't see how that would happen either... can
> you tell me which kernel this happened on (or more precisely, which grsec
> version it was) and whether you can still reproduce it with the latest grsec
> (or PaX) test patch?

The problem is still here, I'm on latests hardened kernel: 2.6.25-hardened-r8.
Not sure about version of grsec/pax patches, probably it's easier for you
to check this, you should know where to look. :)

Here is last 10 records from my kernel log, maybe there will be some
additional information for you which give new ideas. I'm ready to help in
any way debugging this issue, but have no idea what to do - feel free to
direct me. I can try test patches for kernel which you provide, or
something else.


2008-11-08_20:30:03.46138 kern.alert: grsec: denied resource overstep by requesting 201359360 for RLIMIT_STACK against limit 8388608 for /var/qmail/bin/qmail-local[qmail-local:4198] uid/euid:1000/1000 gid/egid:100/100, parent /var/qmail/bin/qmail-local[qmail-local:4195] uid/euid:1000/1000 gid/egid:100/100
2008-11-08_20:30:03.52322 kern.alert: grsec: denied resource overstep by requesting 237776896 for RLIMIT_AS against limit 16000000 for /var/qmail/bin/qmail-smtpd[qmail-smtpd:4181] uid/euid:201/201 gid/egid:200/200, parent /usr/bin/tcpserver[tcpserver:1393] uid/euid:201/201 gid/egid:200/200
2008-11-08_20:36:58.13311 kern.alert: grsec: From 74.6.18.224: denied resource overstep by requesting 71270400 for RLIMIT_STACK against limit 8388608 for /bin/cat[cat:5103] uid/euid:81/81 gid/egid:81/81, parent /usr/sbin/apache2[apache2:31931] uid/euid:81/81 gid/egid:81/81
2008-11-08_21:20:39.81525 kern.alert: grsec: From 89.152.88.136: denied resource overstep by requesting 116932608 for RLIMIT_STACK against limit 8388608 for /bin/cat[cat:10926] uid/euid:81/81 gid/egid:81/81, parent /usr/sbin/apache2[apache2:31245] uid/euid:81/81 gid/egid:81/81
2008-11-08_21:21:58.66969 kern.alert: grsec: From 89.152.88.136: denied resource overstep by requesting 190038016 for RLIMIT_STACK against limit 8388608 for /bin/cat[cat:11107] uid/euid:81/81 gid/egid:81/81, parent /usr/sbin/apache2[apache2:7343] uid/euid:81/81 gid/egid:81/81
2008-11-08_21:40:03.24127 kern.alert: grsec: From 190.18.168.208: denied resource overstep by requesting 108195840 for RLIMIT_AS against limit 16000000 for /var/qmail/bin/qmail-smtpd[qmail-smtpd:13392] uid/euid:201/201 gid/egid:200/200, parent /usr/bin/tcpserver[tcpserver:1393] uid/euid:201/201 gid/egid:200/200
2008-11-08_21:44:35.41418 kern.alert: grsec: From 190.18.168.208: denied resource overstep by requesting 193503232 for RLIMIT_AS against limit 16000000 for /var/qmail/bin/qmail-smtpd[qmail-smtpd:13977] uid/euid:201/201 gid/egid:200/200, parent /usr/bin/tcpserver[tcpserver:1393] uid/euid:201/201 gid/egid:200/200
2008-11-08_22:00:03.85310 kern.alert: grsec: denied resource overstep by requesting 167862272 for RLIMIT_STACK against limit 8388608 for /var/qmail/bin/qmail-local[qmail-local:16688] uid/euid:1000/1000 gid/egid:100/100, parent /var/qmail/bin/qmail-local[qmail-local:16685] uid/euid:1000/1000 gid/egid:100/100
2008-11-08_22:13:56.27917 kern.alert: grsec: From 67.207.142.3: denied resource overstep by requesting 96808960 for RLIMIT_AS against limit 16000000 for /var/qmail/bin/qmail-smtpd[qmail-smtpd:18392] uid/euid:201/201 gid/egid:200/200, parent /usr/bin/tcpserver[tcpserver:1393] uid/euid:201/201 gid/egid:200/200
2008-11-08_22:20:18.01759 kern.alert: grsec: denied resource overstep by requesting 138416128 for RLIMIT_STACK against limit 8388608 for /var/qmail/bin/forward[forward:19399] uid/euid:1000/1000 gid/egid:100/100, parent /var/qmail/bin/qmail-local[qmail-local:19396] uid/euid:1000/1000 gid/egid:100/100

-- 
			WBR, Alex.

Re: [gentoo-hardened] what RLIMIT_STACK mean?

[pageexec]

On 9 Nov 2008 at 0:40, Alex Efros wrote:

> The problem is still here, I'm on latests hardened kernel: 2.6.25-hardened-r8.
> Not sure about version of grsec/pax patches, probably it's easier for you
> to check this, you should know where to look. :)

hmm that's a bit too old kernel for us, can you try your .config with a more
recent one, preferably .27.5 that spender just put up on his test page? what
is really weird is that you're not seeing segfaults, only grsec's reporting,
that's the part that doesn't make sense to me yet (also that noone reported
similar problems so far).

Re: [gentoo-hardened] what RLIMIT_STACK mean?

[atoth]

Some error messages like this shows up from time to time every twice months:
"
grsec: (root:U:/bin/rm) denied resource overstep by requesting 115310592
for RLIMIT_STACK against limit 8388608 for /[rm:32461] uid/euid:0/0
gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:32446] uid/euid:0/0
gid/egid:0/0
"
That might be related to the same issue.

Regards,
Dw.
-- 
dr Tóth Attila, Radiológus Szakorvos jelölt, 06-20-825-8057, 06-30-5962-962
Attila Toth MD, Radiologist in Training, +36-20-825-8057, +36-30-5962-962

On Szo, November 8, 2008 22:55, pageexec@freemail.hu wrote:
> On 9 Nov 2008 at 0:40, Alex Efros wrote:
>
>> The problem is still here, I'm on latests hardened kernel:
>> 2.6.25-hardened-r8.
>> Not sure about version of grsec/pax patches, probably it's easier for
>> you
>> to check this, you should know where to look. :)
>
> hmm that's a bit too old kernel for us, can you try your .config with a
> more
> recent one, preferably .27.5 that spender just put up on his test page?
> what
> is really weird is that you're not seeing segfaults, only grsec's
> reporting,
> that's the part that doesn't make sense to me yet (also that noone
> reported
> similar problems so far).
>
>

Re: [gentoo-hardened] what RLIMIT_STACK mean?

[pageexec]

On 9 Nov 2008 at 0:06, atoth@atoth.sote.hu wrote:

> Some error messages like this shows up from time to time every twice months:
> "
> grsec: (root:U:/bin/rm) denied resource overstep by requesting 115310592
> for RLIMIT_STACK against limit 8388608 for /[rm:32461] uid/euid:0/0
> gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:32446] uid/euid:0/0
> gid/egid:0/0
> "
> That might be related to the same issue.

what's your kernel version? and if it's not .27.x, can you test there as well?
also can you reproduce it with even more trivial things like pwd?

Re: [gentoo-hardened] what RLIMIT_STACK mean?

[atoth]

I'm using the latest hardened kernel. I've switched to 2.6.27 on Sunday.
I have /bin/rm only in one daily cron job. And this error message is not
reproducible in a repetitive manner. These error messages showed up in the
logs once per every second months. I try to find a way to trigger it, but
I'm not sure about my success.

It would be good from Alex to provide his recipe for me to try out.

Regards,
Dwokfur
-- 
dr Tóth Attila, Radiológus Szakorvos jelölt, 06-20-825-8057, 06-30-5962-962
Attila Toth MD, Radiologist in Training, +36-20-825-8057, +36-30-5962-962

On Vas, November 9, 2008 12:44, pageexec@freemail.hu wrote:
> On 9 Nov 2008 at 0:06, atoth@atoth.sote.hu wrote:
>
>> Some error messages like this shows up from time to time every twice
>> months:
>> "
>> grsec: (root:U:/bin/rm) denied resource overstep by requesting 115310592
>> for RLIMIT_STACK against limit 8388608 for /[rm:32461] uid/euid:0/0
>> gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:32446] uid/euid:0/0
>> gid/egid:0/0
>> "
>> That might be related to the same issue.
>
> what's your kernel version? and if it's not .27.x, can you test there as
> well?
> also can you reproduce it with even more trivial things like pwd?
>
>

Re: [gentoo-hardened] what RLIMIT_STACK mean?

[Alex Efros]

Hi!

On Mon, Nov 10, 2008 at 07:13:52AM +0100, atoth@atoth.sote.hu wrote:
> It would be good from Alex to provide his recipe for me to try out.

This one doesn't trigger it on your system?
    for i in $(seq 1 10); do perl -e 'exec @ARGV' /bin/pwd; done
Can you show your cron job then?

-- 
			WBR, Alex.

Re: [gentoo-hardened] what RLIMIT_STACK mean?

[atoth]

Dear Alex,

Your one liner triggers the message on my system:
"grsec: (atoth:U:/) denied resource overstep by requesting 137445376 for
RLIMIT_STACK against limit 8388608 for /bin/pwd[pwd:23459]
uid/euid:1000/1000 gid/egid:100/100, parent /bin/bash[bash:23425]
uid/euid:1000/1000 gid/egid:100/100"

The only cron job which contains "rm" is rkhunter's daily script. However
the message showed up very rarely on my system. And not always with "rm".
Since I could find a way to reproduce it, I pushed that issue in the
background and stayed there for long until now.

To pageexec:
I'm reporting the symptom using a 2.6.27-hardened, which is based on
2.6.27.4 and uses grsec-2.1.12-2.6.27.4-200811011834

To Alex:
CONFIG_GRKERNSEC_RESLOG is the kernel option IMHO which makes these
messages visible. That's why you can't see it with PaX alone. It can be an
error how grsec tries to detect limit violations, but there can also be a
flaw in the implementation in some userspace component of the system.
I usually have some of these while I'm listening to music:
grsec: (atoth:U:/usr/bin/audacious) denied resource overstep by requesting
135168 for RLIMIT_MEMLOCK against limit 32768 for
/usr/bin/audacious[audacious:24077] uid/euid:1000/1000 gid/egid:100/100,
parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
and usual report about signal 11s for eg. with java while browsing. Of
course that RLMIT_MEMLOCK value requested is not so insane like that for
perl & pwd.

Question is: do you use a hardened toolchain pie-ssp enabled, or a
regular? It would be interesting to test it using a non-hardened userland
with a grsec-enabled kernel...

Regards,
Dw.
-- 
dr Tóth Attila, Radiológus Szakorvos jelölt, 06-20-825-8057, 06-30-5962-962
Attila Toth MD, Radiologist in Training, +36-20-825-8057, +36-30-5962-962

On Hét, November 10, 2008 10:24, Alex Efros wrote:
> Hi!
>
> On Mon, Nov 10, 2008 at 07:13:52AM +0100, atoth@atoth.sote.hu wrote:
>> It would be good from Alex to provide his recipe for me to try out.
>
> This one doesn't trigger it on your system?
>     for i in $(seq 1 10); do perl -e 'exec @ARGV' /bin/pwd; done
> Can you show your cron job then?
>
> --
> 			WBR, Alex.
>

Re: [gentoo-hardened] what RLIMIT_STACK mean?

[Alex Efros]

Hi!

On Mon, Nov 10, 2008 at 12:31:17PM +0100, atoth@atoth.sote.hu wrote:
> Question is: do you use a hardened toolchain pie-ssp enabled, or a
> regular? It would be interesting to test it using a non-hardened userland
> with a grsec-enabled kernel...

I use hardened toolchain, but it's ease to test with non-hardened:

home ~ # gcc-config -l
 [1] i686-pc-linux-gnu-3.4.6 *
 [2] i686-pc-linux-gnu-3.4.6-hardenednopie
 [3] i686-pc-linux-gnu-3.4.6-hardenednopiessp
 [4] i686-pc-linux-gnu-3.4.6-hardenednossp
 [5] i686-pc-linux-gnu-3.4.6-vanilla
home ~ # gcc-config 5
home ~ # source /etc/profile
home ~ # emerge perl coreutils
...

No, that doesn't change anything. The
    perl -e 'exec $ARGV[0]' /bin/pwd
is still report in kernel log:
2008-11-10_12:22:46.77911 kern.alert: grsec: denied resource overstep by
requesting 164823040 for RLIMIT_STACK against limit 8388608 for
/bin/pwd[pwd:25759] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:1828]
uid/euid:0/0 gid/egid:0/0

-- 
			WBR, Alex.

Re: [gentoo-hardened] what RLIMIT_STACK mean?

[Brian Kroth]

atoth@atoth.sote.hu <atoth@atoth.sote.hu> 2008-11-10 12:31:
> I usually have some of these while I'm listening to music:
> grsec: (atoth:U:/usr/bin/audacious) denied resource overstep by requesting
> 135168 for RLIMIT_MEMLOCK against limit 32768 for
> /usr/bin/audacious[audacious:24077] uid/euid:1000/1000 gid/egid:100/100,
> parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
> and usual report about signal 11s for eg. with java while browsing. Of
> course that RLMIT_MEMLOCK value requested is not so insane like that for
> perl & pwd.

Same here:

grsec: denied resource overstep by requesting 69632 for RLIMIT_MEMLOCK
against limit 32768 for /usr/bin/aplay[aplay:16674] uid/euid:1000/1000
gid/egid:1000/1000, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0

And for the perl forloop:

grsec: denied resource overstep by requesting 4511036391424 for
RLIMIT_STACK against limit 8388608 for /bin/pwd[pwd:18765]
uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:18636]
uid/euid:1000/1000 gid/egid:1000/1000

For me, nothing ever crashed so I just started to ignore them.  I did
wonder at them though.

> Question is: do you use a hardened toolchain pie-ssp enabled, or a
> regular? It would be interesting to test it using a non-hardened userland
> with a grsec-enabled kernel...

$ eselect profile show
Current make.profile symlink:
  /usr/portage/profiles/default/linux/amd64/2008.0/desktop

$ uname -a
Linux omnius 2.6.26-hardened-r2 #3 SMP Sat Oct 4 16:00:09 CDT 2008
x86_64 Intel(R) Xeon(R) CPU X3220 @ 2.40GHz GenuineIntel GNU/Linux

I'll try with a 2.6.27 based one later today.

Brian

Re: [gentoo-hardened] what RLIMIT_STACK mean?

[pageexec]

On 10 Nov 2008 at 7:24, Brian Kroth wrote:

> atoth@atoth.sote.hu <atoth@atoth.sote.hu> 2008-11-10 12:31:
> > I usually have some of these while I'm listening to music:
> > grsec: (atoth:U:/usr/bin/audacious) denied resource overstep by requesting
> > 135168 for RLIMIT_MEMLOCK against limit 32768 for
> > /usr/bin/audacious[audacious:24077] uid/euid:1000/1000 gid/egid:100/100,
> > parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
> > and usual report about signal 11s for eg. with java while browsing. Of
> > course that RLMIT_MEMLOCK value requested is not so insane like that for
> > perl & pwd.
> 
> Same here:
> 
> grsec: denied resource overstep by requesting 69632 for RLIMIT_MEMLOCK
> against limit 32768 for /usr/bin/aplay[aplay:16674] uid/euid:1000/1000
> gid/egid:1000/1000, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0

the memlock limit overstep is harmless, it won't cause any application
per se and you can get rid of it by granting the user in question a higher
limit for mlockable pages (the 32k is the linux default since 2.6.9 or so).

> And for the perl forloop:
> 
> grsec: denied resource overstep by requesting 4511036391424 for
> RLIMIT_STACK against limit 8388608 for /bin/pwd[pwd:18765]
> uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:18636]
> uid/euid:1000/1000 gid/egid:1000/1000

now this one definitely looks fishy and spender's looking into it already.

Re: [gentoo-hardened] what RLIMIT_STACK mean?

[atoth]

On Hét, November 10, 2008 13:43, pageexec@freemail.hu wrote:
> On 10 Nov 2008 at 7:24, Brian Kroth wrote:
>
>> atoth@atoth.sote.hu <atoth@atoth.sote.hu> 2008-11-10 12:31:
>> > I usually have some of these while I'm listening to music:
>> > grsec: (atoth:U:/usr/bin/audacious) denied resource overstep by
>> requesting
>> > 135168 for RLIMIT_MEMLOCK against limit 32768 for
>> > /usr/bin/audacious[audacious:24077] uid/euid:1000/1000
>> gid/egid:100/100,
>> > parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
>> > and usual report about signal 11s for eg. with java while browsing. Of
>> > course that RLMIT_MEMLOCK value requested is not so insane like that
>> for
>> > perl & pwd.
>>
>> Same here:
>>
>> grsec: denied resource overstep by requesting 69632 for RLIMIT_MEMLOCK
>> against limit 32768 for /usr/bin/aplay[aplay:16674] uid/euid:1000/1000
>> gid/egid:1000/1000, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
>
> the memlock limit overstep is harmless, it won't cause any application
> per se and you can get rid of it by granting the user in question a higher
> limit for mlockable pages (the 32k is the linux default since 2.6.9 or
> so).

That's why I ignored these.

>
>> And for the perl forloop:
>>
>> grsec: denied resource overstep by requesting 4511036391424 for
>> RLIMIT_STACK against limit 8388608 for /bin/pwd[pwd:18765]
>> uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:18636]
>> uid/euid:1000/1000 gid/egid:1000/1000
>
> now this one definitely looks fishy and spender's looking into it already.
>
>

If the representation of the resource's amount requested is correct, than
there must be something odd with the userland. I tend to suspect the
latter.

Regards,
Dw.

Re: [gentoo-hardened] what RLIMIT_STACK mean?

[Kerin Millar]

2008/11/10  <pageexec@freemail.hu>:
> On 10 Nov 2008 at 7:24, Brian Kroth wrote:
>
>> atoth@atoth.sote.hu <atoth@atoth.sote.hu> 2008-11-10 12:31:

[snip]

>> grsec: denied resource overstep by requesting 4511036391424 for
>> RLIMIT_STACK against limit 8388608 for /bin/pwd[pwd:18765]
>> uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:18636]
>> uid/euid:1000/1000 gid/egid:1000/1000
>
> now this one definitely looks fishy and spender's looking into it already.

I experience a similar pattern with postfix. Here's a recent excerpt
from my kernel buffer:

[   59.748463] grsec: denied resource overstep by requesting
6014915829760 for RLIMIT_STACK against limit 8388608 for
/etc/postfix/postfix-script[postfix-script:2981] uid/euid:0/0
gid/egid:0/0, parent /lib64/rc/sh/runscript.sh[runscript.sh:2962]
uid/euid:0/0 gid/egid:0/0
[91229.698383] grsec: From 212.183.136.195: denied resource overstep
by requesting 2982265733120 for RLIMIT_STACK against limit 8388608 for
/etc/postfix/postfix-script[postfix-script:15670] uid/euid:0/0
gid/egid:0/0, parent /lib64/rc/sh/runscript.sh[runscript.sh:15663]
uid/euid:0/0 gid/egid:0/0
[91466.615149] grsec: From 212.183.136.195: denied resource overstep
by requesting 7585593999360 for RLIMIT_STACK against limit 8388608 for
/etc/postfix/postfix-script[postfix-script:15876] uid/euid:0/0
gid/egid:0/0, parent /lib64/rc/sh/runscript.sh[runscript.sh:15869]
uid/euid:0/0 gid/egid:0/0
[91852.302529] grsec: From 212.183.136.195: denied resource overstep
by requesting 4286678908928 for RLIMIT_STACK against limit 8388608 for
/etc/postfix/postfix-script[postfix-script:16148] uid/euid:0/0
gid/egid:0/0, parent /lib64/rc/sh/runscript.sh[runscript.sh:16141]
uid/euid:0/0 gid/egid:0/0
[97084.194476] grsec: From 192.168.254.88: denied resource overstep by
requesting 12760106696704 for RLIMIT_STACK against limit 8388608 for
/etc/postfix/postfix-script[postfix-script:18069] uid/euid:0/0
gid/egid:0/0, parent /lib64/rc/sh/runscript.sh[runscript.sh:18062]
uid/euid:0/0 gid/egid:0/0
[97084.591375] grsec: From 192.168.254.88: denied resource overstep by
requesting 6147866898432 for RLIMIT_STACK against limit 8388608 for
/etc/postfix/postfix-script[postfix-script:18084] uid/euid:0/0
gid/egid:0/0, parent /lib64/rc/sh/runscript.sh[runscript.sh:18076]
uid/euid:0/0 gid/egid:0/0
[97104.279223] grsec: From 192.168.254.88: denied resource overstep by
requesting 3078062882816 for RLIMIT_STACK against limit 8388608 for
/etc/postfix/postfix-script[postfix-script:18183] uid/euid:0/0
gid/egid:0/0, parent /lib64/rc/sh/runscript.sh[runscript.sh:18175]
uid/euid:0/0 gid/egid:0/0
[98499.165117] grsec: From 192.168.254.88: denied resource overstep by
requesting 973333118976 for RLIMIT_STACK against limit 8388608 for
/etc/postfix/postfix-script[postfix-script:18685] uid/euid:0/0
gid/egid:0/0, parent /lib64/rc/sh/runscript.sh[runscript.sh:18677]
uid/euid:0/0 gid/egid:0/0
[335157.025790] grsec: From 212.183.134.66: denied resource overstep
by requesting 10497186820096 for RLIMIT_STACK against limit 8388608
for /etc/postfix/postfix-script[postfix-script:1557] uid/euid:0/0
gid/egid:0/0, parent /lib64/rc/sh/runscript.sh[runscript.sh:1550]
uid/euid:0/0 gid/egid:0/0
[431086.838131] grsec: From 192.168.254.88: denied resource overstep
by requesting 3096323715072 for RLIMIT_STACK against limit 8388608 for
/etc/postfix/postfix-script[postfix-script:23575] uid/euid:0/0
gid/egid:0/0, parent /lib64/rc/sh/runscript.sh[runscript.sh:23568]
uid/euid:0/0 gid/egid:0/0

This has been going on for a long time now. I had assumed that postfix
was to blame and was intending to investigate further at some point
(but, of course, I never did). If there is anything that I can do that
may help to shed light on the matter then please do let me know.

Cheers,

--Kerin

Re: [gentoo-hardened] what RLIMIT_STACK mean?

[pageexec]

On 12 Nov 2008 at 0:00, Kerin Millar wrote:

> This has been going on for a long time now. I had assumed that postfix
> was to blame and was intending to investigate further at some point
> (but, of course, I never did). If there is anything that I can do that
> may help to shed light on the matter then please do let me know.

we're already debugging it, it's something due to ASLR. if you want to help
as well, add a __WARN() call to where grsec reports this and send me the
backtraces please.

Re: [gentoo-hardened] what RLIMIT_STACK mean?

[Alex Efros]

Hi!

On Sat, Nov 08, 2008 at 11:55:05PM +0200, pageexec@freemail.hu wrote:
> hmm that's a bit too old kernel for us, can you try your .config with a more
> recent one, preferably .27.5 that spender just put up on his test page? what

I've tried sys-kernel/vanilla-sources-2.6.27.5 with (separately) both
pax-linux-2.6.27.5-test13.patch and
grsecurity-2.1.12-2.6.27.5-200811071900.patch

I boot kernel with init=/bin/bash and run that script:

    #!/bin/sh
    mount -n -t ramfs none /dev
    mknod -m 660 /dev/console c 5 1
    mknod -m 660 /dev/null c 1 3
    perl -e 'exec @ARGV' /bin/pwd

with PaX patch I don't see anything in dmesg, with grsec patch I see this
approx on each second execution of above script:

grsec: denied resource overstep by requesting 191062016 for RLIMIT_STACK against limit 8388608 for /bin/pwd[pwd:596] uid/euid:0/0 gid/egid:0/0, parent /tmp/pwd[pwd:592] uid/euid:0/0 gid/egid:0/0
grsec: denied resource overstep by requesting 246771712 for RLIMIT_STACK against limit 8388608 for /bin/pwd[pwd:611] uid/euid:0/0 gid/egid:0/0, parent /tmp/pwd[pwd:607] uid/euid:0/0 gid/egid:0/0
grsec: denied resource overstep by requesting 123482112 for RLIMIT_STACK against limit 8388608 for /bin/pwd[pwd:616] uid/euid:0/0 gid/egid:0/0, parent /tmp/pwd[pwd:612] uid/euid:0/0 gid/egid:0/0

-- 
			WBR, Alex.