grsecurity forums

by **hardigunawan** » Fri Mar 07, 2003 5:15 am

Hi,

I've this error when running my own created program:
attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (master:1188) UID(0) EUID(0), parent (bash:1050) UID(0) EUID(0)

I'm using grsec 1.9.9c with no ACL. Here's my kernel's config:
#
# Grsecurity
#
CONFIG_GRKERNSEC=y
# CONFIG_GRKERNSEC_LOW is not set
# CONFIG_GRKERNSEC_MID is not set
# CONFIG_GRKERNSEC_HI is not set
CONFIG_GRKERNSEC_CUSTOM=y

#
# Address Space Protection
#
# CONFIG_GRKERNSEC_PAX_NOEXEC is not set
CONFIG_GRKERNSEC_PAX_ASLR=y
# CONFIG_GRKERNSEC_PAX_RANDKSTACK is not set
CONFIG_GRKERNSEC_PAX_RANDUSTACK=y
CONFIG_GRKERNSEC_PAX_RANDMMAP=y
# CONFIG_GRKERNSEC_KMEM is not set
# CONFIG_GRKERNSEC_IO is not set
CONFIG_GRKERNSEC_PROC_MEMMAP=y

#
# ACL options
#
CONFIG_GRKERNSEC_ACL_HIDEKERN=y
CONFIG_GRKERNSEC_ACL_MAXTRIES=3
CONFIG_GRKERNSEC_ACL_TIMEOUT=30

#
# Filesystem Protections
#
CONFIG_GRKERNSEC_PROC=y
CONFIG_GRKERNSEC_PROC_USER=y
CONFIG_GRKERNSEC_PROC_ADD=y
CONFIG_GRKERNSEC_LINK=y
CONFIG_GRKERNSEC_FIFO=y
CONFIG_GRKERNSEC_CHROOT=y
CONFIG_GRKERNSEC_CHROOT_MOUNT=y
CONFIG_GRKERNSEC_CHROOT_DOUBLE=y
CONFIG_GRKERNSEC_CHROOT_PIVOT=y
CONFIG_GRKERNSEC_CHROOT_CHDIR=y
CONFIG_GRKERNSEC_CHROOT_CHMOD=y
CONFIG_GRKERNSEC_CHROOT_FCHDIR=y
CONFIG_GRKERNSEC_CHROOT_MKNOD=y
CONFIG_GRKERNSEC_CHROOT_SHMAT=y
CONFIG_GRKERNSEC_CHROOT_UNIX=y
CONFIG_GRKERNSEC_CHROOT_FINDTASK=y
CONFIG_GRKERNSEC_CHROOT_NICE=y
CONFIG_GRKERNSEC_CHROOT_SYSCTL=y
CONFIG_GRKERNSEC_CHROOT_CAPS=y

#
# Kernel Auditing
#
CONFIG_GRKERNSEC_AUDIT_GROUP=y
CONFIG_GRKERNSEC_AUDIT_GID=1007
CONFIG_GRKERNSEC_EXECLOG=y
CONFIG_GRKERNSEC_RESLOG=y
CONFIG_GRKERNSEC_CHROOT_EXECLOG=y
CONFIG_GRKERNSEC_AUDIT_CHDIR=y
CONFIG_GRKERNSEC_AUDIT_MOUNT=y
CONFIG_GRKERNSEC_AUDIT_IPC=y
CONFIG_GRKERNSEC_SIGNAL=y
CONFIG_GRKERNSEC_FORKFAIL=y
CONFIG_GRKERNSEC_TIME=y

#
# Executable Protections
#
CONFIG_GRKERNSEC_EXECVE=y
CONFIG_GRKERNSEC_DMESG=y
CONFIG_GRKERNSEC_RANDPID=y
CONFIG_GRKERNSEC_TPE=y
CONFIG_GRKERNSEC_TPE_ALL=y
CONFIG_GRKERNSEC_TPE_GID=1005

#
# Network Protections
#
CONFIG_GRKERNSEC_RANDNET=y
CONFIG_GRKERNSEC_RANDISN=y
CONFIG_GRKERNSEC_RANDID=y
CONFIG_GRKERNSEC_RANDSRC=y
CONFIG_GRKERNSEC_RANDRPC=y
CONFIG_GRKERNSEC_RANDPING=y
CONFIG_GRKERNSEC_SOCKET=y
CONFIG_GRKERNSEC_SOCKET_ALL=y
CONFIG_GRKERNSEC_SOCKET_ALL_GID=1004
CONFIG_GRKERNSEC_SOCKET_CLIENT=y
CONFIG_GRKERNSEC_SOCKET_CLIENT_GID=1003
CONFIG_GRKERNSEC_SOCKET_SERVER=y
CONFIG_GRKERNSEC_SOCKET_SERVER_GID=1002

#
# Sysctl support
#
CONFIG_GRKERNSEC_SYSCTL=y

#
# Miscellaneous Features
#
CONFIG_GRKERNSEC_FLOODTIME=10
CONFIG_GRKERNSEC_FLOODBURST=4

I've tried to disable everything using chpax:
----[ chpax 0.2 : Current flags for master ]----

* Paging based PAGE_EXEC : disabled
* Trampolines : not emulated
* mprotect() : not restricted
* mmap() base : not randomized
* ET_EXEC base : not randomized
* Segmentation based PAGE_EXEC : disabled

What should I do to solve this? My program works with kernel without grsecurity.

by **hightower** » Fri Mar 07, 2003 9:20 am

Hi

hardigunawan wrote:attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (master:1188) UID(0) EUID(0), parent (bash:1050) UID(0) EUID(0)

What should I do to solve this? My program works with kernel without grsecurity.

Well, nothing PaX related. The error is very obvious. Your program requests 4096 for RLIMIT_CORE (ulimit -c) but you have a limit of 0 (disabled core).

ciao, Marc

by **spender** » Fri Mar 07, 2003 9:50 am

use ulimit -c to check your limit for core files. The reason why your app is coredumping is because there's a bug in it. Grsecurity isn't causing the problem, it's just logging it.

-Brad

by **supermike** » Mon Mar 31, 2003 2:07 pm

I'm having the same problem with programs such as java and coldfusion.
eg:
...attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (cfusion:15811) UID(101) EUID(101), parent (cfusion:4317) UID(101) EUID(101)

Keeping the limit for core at 0 with a non-grsec kernel works. (Disabled pax on the binaries and they still do not run).

by **erich** » Tue Apr 01, 2003 12:16 pm

apt-proxy doesn't work any more since i'm running wolk with current grsecurity...

kernel: grsec: From 10.0.0.5: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (apt-proxy:20329) UID(108) EUID(108), parent (apt-proxy:19330) UID(108) EUID(108)

apt-proxy is a shell script, it does not contain "ulimit", or any similar calls as far as i can tell.

kernel: grsec: attempted resource overstep by requesting 31825920 for RLIMIT_STACK against limit 8388608 by (pidof:1154) UID(0) EUID(0), parent (init:1) UID(0) EUID(0)

Something is really weird here. Especially since grsecurity claims to do logging only: why does the program apt-proxy no longer work properly? Something must have changed there.
Note: i have ACLs /not/ enabled yet.

by **spender** » Tue Apr 01, 2003 1:45 pm

Maybe WOLK merged incorrectly. Have you tried a clean 2.4.20 kernel with just the grsecurity 1.9.9e patch? Does apt-proxy actually not work, or is the problem just the log about the signal?
(Also, I have no problems running apt-proxy here)

-Brad

by **supermike** » Wed Apr 02, 2003 3:33 pm

there must be some change between 1.9.8 and 1.9.9, since using 1.9.9 it seems any executable that I need to disable pax for will not run (& grsec logs that RLIMIT_CORE msg)

by **spender** » Wed Apr 02, 2003 3:38 pm

Are you using WOLK or a clean kernel with just grsecurity? What grsecurity version are you using?

-Brad

by **supermike** » Wed Apr 02, 2003 3:42 pm

I'm not using wolk, just a clean kernel w/grsec 1.9.9d
I believe I had the same problem w/1.9.9b but not 1.9.8

by **PaX Team** » Wed Apr 02, 2003 4:33 pm

supermike wrote:there must be some change between 1.9.8 and 1.9.9, since using 1.9.9 it seems any executable that I need to disable pax for will not run (& grsec logs that RLIMIT_CORE msg)

can you give me a few example apps and what PaX flags you disabled on them?

by **supermike** » Wed Apr 02, 2003 4:59 pm

----[ chpax 0.2 : Current flags for /usr/java/bin/java ]----
* Paging based PAGE_EXEC : enabled
* Trampolines : not emulated
* mprotect() : restricted
* mmap() base : randomized
* ET_EXEC base : not randomized
* Segmentation based PAGE_EXEC : disabled

same flags for cfusion, tried disabling others but only seg based relevant?

options:
CONFIG_GRKERNSEC_PAX_NOEXEC=y
# CONFIG_GRKERNSEC_PAX_PAGEEXEC is not set
CONFIG_GRKERNSEC_PAX_SEGMEXEC=y
# CONFIG_GRKERNSEC_PAX_EMUTRAMP is not set
CONFIG_GRKERNSEC_PAX_MPROTECT=y
# CONFIG_GRKERNSEC_PAX_NOELFRELOCS is not set
CONFIG_GRKERNSEC_PAX_ASLR=y
CONFIG_GRKERNSEC_PAX_RANDKSTACK=y
CONFIG_GRKERNSEC_PAX_RANDUSTACK=y
CONFIG_GRKERNSEC_PAX_RANDMMAP=y
# CONFIG_GRKERNSEC_PAX_RANDEXEC is not set
CONFIG_GRKERNSEC_KMEM=y
CONFIG_GRKERNSEC_IO=y
CONFIG_RTC=y
CONFIG_GRKERNSEC_PROC_MEMMAP=y

by **PaX Team** » Wed Apr 02, 2003 5:18 pm

supermike wrote:----[ chpax 0.2 : Current flags for /usr/java/bin/java ]----

isn't it java_vm by any chance that needs some PaX features disabled?

* Paging based PAGE_EXEC : enabled
* Trampolines : not emulated
* mprotect() : restricted
* mmap() base : randomized
* ET_EXEC base : not randomized
* Segmentation based PAGE_EXEC : disabled

java works here without any restrictions, java_vm needs the above but then it works fine (it's from Sun J2RE 1.4.0_01).

same flags for cfusion, tried disabling others but only seg based relevant?

indeed, since you didn't enable PAGEEXEC in the kernel. could i ask you to try the vanilla kernel with only PaX applied and see what happens? this would help decide whether it's something in PaX or grsec itself. also try disabling randomization to see if that makes a difference.

by **supermike** » Wed Apr 02, 2003 6:08 pm

(I did actually have the flag disabled on java_vm as well).

So, I just tried what you suggested, compiled a new kernel with only the PAX options, all grsec features off and it works.

by **PaX Team** » Wed Apr 02, 2003 6:27 pm

supermike wrote:So, I just tried what you suggested, compiled a new kernel with only the PAX options, all grsec features off and it works.

ok, so this means one of the grsec options causes this behaviour. now if you still have some time for kernel compilation/testing, you could try to eliminate the options you had enabled and see when the problem goes away.

by **supermike** » Wed Apr 02, 2003 6:30 pm

I knew you were going to ask that

Ok, already re-enabled randomization and it now fails again:
CONFIG_GRKERNSEC_PAX_ASLR=y
CONFIG_GRKERNSEC_PAX_RANDKSTACK=y
CONFIG_GRKERNSEC_PAX_RANDUSTACK=y
CONFIG_GRKERNSEC_PAX_RANDMMAP=y

Only difference is I don't get the log message from grsec of course.

grsecurity forums

attempted resource overstep

attempted resource overstep

Re: attempted resource overstep

Something is BROKEN with resource limits.