gmane.linux.gentoo.hardened

Alex Efros | 27 Sep 14:41

what RLIMIT_STACK mean?

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@...>
    qp 22534 uid 201

(Continue reading)

Alex Efros | 29 Sep 17:21

Re: what RLIMIT_STACK mean?

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

(Continue reading)

"Javier =?iso | 29 Sep 17:46

Re: what RLIMIT_STACK mean?

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@...>:
> 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),

(Continue reading)

Alex Efros | 29 Sep 17:56

Re: what RLIMIT_STACK mean?

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

(Continue reading)

"Javier =?iso | 29 Sep 18:06

Re: what RLIMIT_STACK mean?

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@...>:
> 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...),

(Continue reading)

"Javier =?iso | 29 Sep 18:10

Re: what RLIMIT_STACK mean?

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@...>:
> 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@...>:
>> 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.
>>

(Continue reading)

Alex Efros | 29 Sep 18:24

Re: what RLIMIT_STACK mean?

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

(Continue reading)

pageexec | 29 Sep 18:46

Re: what RLIMIT_STACK mean?

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.

Alex Efros | 29 Sep 18:57

Re: what RLIMIT_STACK mean?

Hi!

On Mon, Sep 29, 2008 at 06:46:18PM +0200, pageexec@... 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.

(Continue reading)

Adam James | 30 Sep 01:29

Re: what RLIMIT_STACK mean?

On Mon, 29 Sep 2008 19:57:02 +0300
Alex Efros <powerman@...> 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.

(Continue reading)

Alex Efros | 30 Sep 02:03

Re: what RLIMIT_STACK mean?

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.

pageexec | 8 Nov 22:13

Re: what RLIMIT_STACK mean?

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?

Alex Efros | 8 Nov 23:40

Re: what RLIMIT_STACK mean?

Hi!

On Sat, Nov 08, 2008 at 11:13:47PM +0200, pageexec@... 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

(Continue reading)

pageexec | 8 Nov 22:55

Re: what RLIMIT_STACK mean?

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).

atoth | 9 Nov 00:06

Re: what RLIMIT_STACK mean?

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@... 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,

(Continue reading)

pageexec | 9 Nov 12:44

Re: what RLIMIT_STACK mean?

On 9 Nov 2008 at 0:06, atoth@... 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?

atoth | 10 Nov 07:13

Re: what RLIMIT_STACK mean?

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@... wrote:
> On 9 Nov 2008 at 0:06, atoth@... 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?

(Continue reading)

Alex Efros | 10 Nov 10:24

Re: what RLIMIT_STACK mean?

Hi!

On Mon, Nov 10, 2008 at 07:13:52AM +0100, atoth@... 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.

atoth | 10 Nov 12:31

Re: what RLIMIT_STACK mean?

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.

(Continue reading)

Alex Efros | 10 Nov 13:23

Re: what RLIMIT_STACK mean?

Hi!

On Mon, Nov 10, 2008 at 12:31:17PM +0100, atoth@... 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.

(Continue reading)

Brian Kroth | 10 Nov 14:24

Re: what RLIMIT_STACK mean?

atoth@...
<atoth@...> 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...

(Continue reading)

pageexec | 10 Nov 13:43

Re: what RLIMIT_STACK mean?

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

> atoth@...
<atoth@...> 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

(Continue reading)

atoth | 10 Nov 18:02

Re: what RLIMIT_STACK mean?

On Hét, November 10, 2008 13:43, pageexec@... wrote:
> On 10 Nov 2008 at 7:24, Brian Kroth wrote:
>
>> atoth@...
<atoth@...> 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.

(Continue reading)

Kerin Millar | 12 Nov 01:00

Re: what RLIMIT_STACK mean?

2008/11/10  <pageexec@...>:
> On 10 Nov 2008 at 7:24, Brian Kroth wrote:
>
>> atoth@...
<atoth@...> 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

(Continue reading)

pageexec | 12 Nov 01:37

Re: what RLIMIT_STACK mean?

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.

Alex Efros | 9 Nov 18:40

Re: what RLIMIT_STACK mean?

Hi!

On Sat, Nov 08, 2008 at 11:55:05PM +0200, pageexec@... 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.

(Continue reading)

Return

Return to gmane.linux.gentoo.hardened.

Advertisement

Project Web Page

For a security hardened version of Gentoo

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane