gradm errors

[dave]

I'm not quite sure what I've done wrong here... I just finished installing grsecurity-2.0.1 patch on a SuSe 9.1 system -- I managed to jump all the hurdles up to this point. I've got a working system, where I can login. X doesn't quite work, but that's a different issue. Most daemons start up after a little chpax coaxing. But when I try to issue a "gradm -E", I get the following message:

Warning: Unable to lock password into physical memory.
Segmentation fault

In my /var/log/messages, I get:

kernel: PAX: VMMIRROR: fault bug2, baaf8000, baaf8000, 5aaf5000, baaf9000, 5aaf9000
kernel: PAX: VMMIRROR: expand bug, 5aaf4000, 5aaf5000, baaf5000, 5aaf9000, baaf8000
kernel: grsec: signal 11 sent to /usr/local/src/grsecurity/cvsgradm2/gradm2/gradm[gradm:9193] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:2743] uid/euid:0/0 gid/egid:0/0
grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by /usr/local/src/rsecurity/cvsgradm2/gradm2/gradm[gradm:9193] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:2743] uid/euid:0/0 gid/egid:0/0

Here's my kernel .config appropriate parts:

CONFIG_GRKERNSEC=y
CONFIG_GRKERNSEC_CUSTOM=y
CONFIG_GRKERNSEC_KMEM=y
CONFIG_GRKERNSEC_PROC_MEMMAP=y
CONFIG_GRKERNSEC_ACL_HIDEKERN=y
CONFIG_GRKERNSEC_ACL_MAXTRIES=3
CONFIG_GRKERNSEC_ACL_TIMEOUT=30
CONFIG_GRKERNSEC_PROC=y
CONFIG_GRKERNSEC_PROC_USERGROUP=y
CONFIG_GRKERNSEC_PROC_GID=1001
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

CONFIG_GRKERNSEC_RESLOG=y
CONFIG_GRKERNSEC_SIGNAL=y
CONFIG_GRKERNSEC_FORKFAIL=y
CONFIG_GRKERNSEC_TIME=y

CONFIG_GRKERNSEC_EXECVE=y
CONFIG_GRKERNSEC_DMESG=y
CONFIG_GRKERNSEC_RANDPID=y

#NETWORK STUFF

CONFIG_PAX=y
CONFIG_PAX_SOFTMODE=y
CONFIG_PAX_EI_PAX=y
CONFIG_PAX_PT_PAX_FLAGS=y
CONFIG_PAX_NO_ACL_FLAGS=y

CONFIG_PAX_NOEXEC=y
CONFIG_PAX_SEGMEXEC=y

CONFIG_PAX_ASLR=y
CONFIG_PAX_RANDUSTACK=y
CONFIG_PAX_RANDMMAP=y

Help would be highly appreciated! Thanks!

[PaX Team]

kernel: PAX: VMMIRROR: fault bug2, baaf8000, baaf8000, 5aaf5000, baaf9000, 5aaf9000
kernel: PAX: VMMIRROR: expand bug, 5aaf4000, 5aaf5000, baaf5000, 5aaf9000, baaf8000

CONFIG_PAX_NOEXEC=y
CONFIG_PAX_SEGMEXEC=y

i've fixed this bug already just haven't put it into CVS as there're other pending (and not yet finished) changes. for now just enable MPROTECT and it will work.

[dave]

i've fixed this bug already just haven't put it into CVS as there're other pending (and not yet finished) changes. for now just enable MPROTECT and it will work.

is it a change thats independent of other changes, that you could pull a quick 'patch' command on?

i'm not sure if I can enable MPROTECT. I got the the point where the SuSe system was just not going to be able to be used without disabling MPROTECT and putting the PaX system in soft mode --> came to that conclusion by following the threads on gentoo, that either you need to patch gcc and recompile the binaries in question, or just not use MPROTECT. Recompiling almost every significant binary including X, ssh, and many libraries such as PAM, cryptlib, crypt-fs, etc is just not an option.

Long story short... patch?

[PaX Team]

is it a change thats independent of other changes, that you could pull a quick 'patch' command on?

actually, never mind, what i thought would fix your problem has actually been in CVS since june and is now in the grsecurity release as well, so apparently the problem is something else than what i thought it was. now comes the investigation part .

i'm not sure if I can enable MPROTECT. I got the the point where the SuSe system was just not going to be able to be used without disabling MPROTECT

what is this supposed to mean exactly? like what were the symptoms with MPROTECT enabled? have you got any logs/dmesg/etc? also, if the problem is related to PT_GNU_STACK handling, then you're best off by running 'execstack -c' on all binaries that are falsely marked with an executable stack.

came to that conclusion by following the threads on gentoo, that either you need to patch gcc and recompile the binaries in question, or just not use MPROTECT.

not sure what made you think this would be necessary for MPROTECT, what requires recompilation (PT_PAX_FLAGS or PIE support) is independent from MPROTECT support.

[dave]

actually, never mind, what i thought would fix your problem has actually been in CVS since june and is now in the grsecurity release as well, so apparently the problem is something else than what i thought it was. now comes the investigation part .

I must have been confused about the MPROTECT. No matter though, I am about done spending time on trying to get that work, it singlehandedly fubarred every major process on the system... At this point, work needs to move on

The more concerning issue, however, is that of gradm segfaulting. Is there anything else I can provide you with to work that out besides what I've already posted?

[PaX Team]

The more concerning issue, however, is that of gradm segfaulting. Is there anything else I can provide you with to work that out besides what I've already posted?

i need to know the following:

1. kernel tree/version you patched
2. grsec version i know, but i'd like to know what else you patched in, if anything
3. glibc version
4. full strace of a failing app (gradm or others)
5. output of 'cat /proc/self/maps' if you can get it