grsecurity forums

Hey there!

first off all some good news:
grsecurity will be included in the next release of Devil-Linux!

Now to the problem:
kernel 2.4.20 + grsecurity 1.98-rc2 .

Everything seems to work fine, except of the cvs server:
**********
Dec 18 19:49:19 src@cvs-pmx kernel: grsec: From 10.71.148.199: attempted resource overstep by requesting 8003584
for RLIMIT_STACK against limit 8000000 by (cvs:928) UID(603) EUID(603), parent (xinetd:822) UID(0) EUID(0)
**********
When this message appears, the client session dies.

Setting the limit higher just delays the problem and setting "execve_limiting" to 0 in /proc doesn't change a thing.

When I boot with a non grsec-kernel, everything works fine without any problems.

Am I missing / not understanding something or is this a bug?

Thanks
Heiko

devillinux wrote:Everything seems to work fine, except of the cvs server:
**********
Dec 18 19:49:19 src@cvs-pmx kernel: grsec: From 10.71.148.199: attempted resource overstep by requesting 8003584
for RLIMIT_STACK against limit 8000000 by (cvs:928) UID(603) EUID(603), parent (xinetd:822) UID(0) EUID(0)
**********
When this message appears, the client session dies.

Setting the limit higher just delays the problem and setting "execve_limiting" to 0 in /proc doesn't change a thing.

execve_limiting controls RLIMIT_NPROC oversteps, it has no effect on RLIMIT_STACK. second, the above message is just logging an event, it doesn't by itself mean that grsec did something to the task. if you have the ACL system enabled, then you should run cvs in learning mode first. btw, referring to 'setting the limit higher', where and what limit did you set?

Hey there,

I set the limit to 16 MB and to unlimited. With unlimited I ran into an "out of memory" message (of course....).
I set the limit in 2 ways:
1) within xinetd (has this feature as an option for every service)
2) with a wrapper program for cvs

The ACL system is disabled and I won't enable it on that system.

Are you sure that grsec isn't doing anything? When I switched to a non-grsec kernel, everything worked fine (the exact same config disc was used).

I was told that client connections died, after checking the log, it were those clients which caused the rtlimit_stack message.

Thanks for your help
Heiko

devillinux wrote:Are you sure that grsec isn't doing anything? When I switched to a non-grsec kernel, everything worked fine (the exact same config disc was used).

well, of course i'm not sure, i just know that there's no specific anti-cvs code in there . based on the symptoms it seems that cvs is getting into some recursive/infinite loop, it would be nice if you could find out why (by disabling various grsec features). or you can wait for Brad (probably not this year though), as he did manage to set up cvs and doesn't have this problem (afaik).

I was told that client connections died, after checking the log, it were those clients which caused the rtlimit_stack message.

does this mean that there are successful users as well? if so, maybe looking at the differences between them and those who fail might shed some light on the problem (file permissions, groups, etc).

PaX Team wrote:

devillinux wrote:Are you sure that grsec isn't doing anything? When I switched to a non-grsec kernel, everything worked fine (the exact same config disc was used).

well, of course i'm not sure, i just know that there's no specific anti-cvs code in there . based on the symptoms it seems that cvs is getting into some recursive/infinite loop, it would be nice if you could find out why (by disabling various grsec features). or you can wait for Brad (probably not this year though), as he did manage to set up cvs and doesn't have this problem (afaik).

I disabled all the grsec features (in /proc) and it changed nothing.
Yeah I can wait for Brad, I baked a special Devil-Linux version without grsec which runs on that machine at the moment.
We just need to fix this problem, so I can go back to the mainstream ISO and other users won't have it.

I was told that client connections died, after checking the log, it were those clients which caused the rtlimit_stack message.

does this mean that there are successful users as well? if so, maybe looking at the differences between them and those who fail might shed some light on the problem (file permissions, groups, etc).

Yes, some worked some not. There are no differences between the users, except the cvs command they executed, e.g. they're all in the same group.
Let's just wait until Brad is back.

Thanks for your help!

Spender,

looks like your back, can you please take a look at this?

Thx
Heiko

Don't worry about it. It's not a bug in grsecurity, but actually a bug in cvs. It happens when a remote user ctrl+c's a session with the cvs server, which apparently throws the server into a loop that overflows the stack, and then the server aborts itself. It's not grsecurity creating the error, it's simply logging it for you.

-Brad

I'm still scared about the fact, that the users reported problems while I was using the grsec Kernel.

I hope I have some time next week, to try it out again.

Thx
Heiko

They were probably just confused, because they saw grsecurity report an error. If grsecurity wasn't enabled (or if the resource logging wasn't enabled) cvs would still do the same thing, you just wouldn't know it unless you debugged the application.

-Brad