grsecurity forums

I'm attemping to run grsec on a usermode linux machine. Kernel is 2.6.19.2 and operating sytem is gentoo. After the system mounts the root filesystem, it attempts to run /sbin/init which segfaults. I've successfully run this system on a non grsec kernel. Any help would be appreciated

Here is the output when booting:

Code: Select all

Initializing software serial port version 1
 ubda: unknown partition table
 ubdb: unknown partition table
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
grsec: exec of /sbin/init (/sbin/init ) by /[swapper:1] uid/euid:0/0 gid/egid:0/0, parent /[swapper:0] uid/euid:0/0 gid/egid:0/0
grsec: signal 11 sent to /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0, parent /[swapper:0] uid/euid:0/0 gid/egid:0/0
grsec: exec of /bin/bash (/bin/sh ) by /[init:1] uid/euid:0/0 gid/egid:0/0, parent /[swapper:0] uid/euid:0/0 gid/egid:0/0
grsec: signal 11 sent to /bin/bash[sh:1] uid/euid:0/0 gid/egid:0/0, parent /[swapper:0] uid/euid:0/0 gid/egid:0/0
Kernel panic - not syncing: No init found.  Try passing init= option to kernel.


Here are my .config options related to grsec + pax:

Code: Select all

#
# PaX
#

#
# Miscellaneous hardening features
#
# CONFIG_PAX_MEMORY_SANITIZE is not set

#
# Grsecurity
#
CONFIG_GRKERNSEC=y
# CONFIG_GRKERNSEC_LOW is not set
# CONFIG_GRKERNSEC_MEDIUM is not set
# CONFIG_GRKERNSEC_HIGH is not set
CONFIG_GRKERNSEC_CUSTOM=y

#
# Address Space Protection
#
CONFIG_GRKERNSEC_KMEM=y
# CONFIG_GRKERNSEC_BRUTE is not set
# CONFIG_GRKERNSEC_HIDESYM is not set

#
# Role Based Access Control 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 is not set
# CONFIG_GRKERNSEC_LINK is not set
# CONFIG_GRKERNSEC_FIFO is not set
# CONFIG_GRKERNSEC_CHROOT is not set

#
# Kernel Auditing
#
# CONFIG_GRKERNSEC_AUDIT_GROUP is not set
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
# CONFIG_GRKERNSEC_PROC_IPADDR is not set

#
# Executable Protections
#
CONFIG_GRKERNSEC_EXECVE=y
# CONFIG_GRKERNSEC_SHM is not set
CONFIG_GRKERNSEC_DMESG=y
# CONFIG_GRKERNSEC_TPE is not set

#
# Network Protections
#
# CONFIG_GRKERNSEC_RANDNET is not set
# CONFIG_GRKERNSEC_SOCKET is not set

#
# Sysctl support
#
# CONFIG_GRKERNSEC_SYSCTL is not set

#
# Logging Options
#
CONFIG_GRKERNSEC_FLOODTIME=10
CONFIG_GRKERNSEC_FLOODBURST=4
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set


also note i've tried both the nosep and the vdso=0 options. neither fix the problem.

same thing happens w/ kernel 2.6.23.1 and 2.1.11-2.6.23.1-200710301850 with low security profile selected.

comsatcat wrote:I'm attemping to run grsec on a usermode linux machine. Kernel is 2.6.19.2 and operating sytem is gentoo. After the system mounts the root filesystem, it attempts to run /sbin/init which segfaults. I've successfully run this system on a non grsec kernel.

first of all, i've never tried PaX or grsec and UML (guest or host), so i don't know if it ever worked (and if it did, that was more luck than a conscious effort on our part). with that said, what is the setup that fails exactly? vanilla host/grsec guest? or grsec host/grsec guest? i.e., which kernel was 2.6.19.2, guest or host? as for finding the real cause of the crashes and assuming grsec was in the guest, can you just gdb the guest OS and catch/analyze the sigsegv there (you know the usual stuff, x/8i $pc, x/8x $sp, info reg, etc)?

Its a vanilla host (actually RHEL 4). The guest is 2.6.19.2 grsec. -- I've also tried 2.6.23.1 grsec as well.

Here is the output for the 2.6.23.1 gdb:

Code: Select all

(gdb) x /8i $pc
0x7c82c2 <abort+530>:   hlt   
0x7c82c3 <abort+531>:   movl   $0x7f,(%esp)
0x7c82ca <abort+538>:   mov    $0x8,%esi
0x7c82cf <abort+543>:   mov    %esi,0x1330(%ebx)
0x7c82d5 <abort+549>:   call   0x829b64 <_exit>
0x7c82da <abort+554>:   movl   $0x6,(%esp)
0x7c82e1 <abort+561>:   mov    $0x6,%eax
0x7c82e6 <abort+566>:   mov    %eax,0x1330(%ebx)
(gdb)


(gdb) x /8x $sp
0x9075da4:      0x00000006      0x09075e30      0x00000000      0x00000020
0x9075db4:      0x00000000      0x00000000      0x00000000      0x00000000
(gdb)

(gdb) i r
eax            0x6      6
ecx            0x7      7
edx            0x6      6
ebx            0x8c4ff4 9195508
esp            0x9075da4        0x9075da4
ebp            0x9075ecc        0x9075ecc
esi            0x9075e30        151477808
edi            0x0      0
eip            0x7c82c2 0x7c82c2
eflags         0x10246  66118
cs             0x73     115
ss             0x7b     123
ds             0x7b     123
es             0x7b     123
fs             0x0      0
gs             0x33     51
(gdb)

(gdb) bt
#0  0x007c82c2 in abort () from /lib/tls/libc.so.6
#1  0x080646f9 in os_dump_core () at arch/um/os-Linux/util.c:109
#2  0x0805881b in panic_exit (self=0x820a6b4, unused1=0, unused2=0x8220aa0) at arch/um/kernel/um_arch.c:477
#3  0x0807ae87 in notifier_call_chain (nl=0x8220a80, val=0, v=0x8220aa0, nr_to_call=-2, nr_calls=0x0) at kernel/sys.c:174
#4  0x0807af39 in __atomic_notifier_call_chain (nh=0x8220a80, val=0, v=0x8220aa0, nr_to_call=-1, nr_calls=0x0) at kernel/sys.c:267
#5  0x0807af53 in atomic_notifier_call_chain (nh=0x8220a80, val=0, v=0x8220aa0) at kernel/sys.c:277
#6  0x0806ecd2 in panic (fmt=0x81df7f3 "No init found.  Try passing init= option to kernel.") at kernel/panic.c:99
#7  0x08054ddd in init_post () at init/main.c:822
#8  0x0804982f in kernel_init (unused=0x0) at init/main.c:876
#9  0x08062e69 in run_kernel_thread (fn=0x8049794 <kernel_init>, arg=0x0, jmp_ptr=0x87cb8c4) at arch/um/os-Linux/process.c:295
#10 0x08058c99 in new_thread_handler () at include/asm/thread_info.h:48
#11 0x00000000 in ?? ()
(gdb)


That really just looks like the kernel panic and not info related to grsec.. hope this helps though.

Just to try to narrow down the offending feature, can you try using a kernel that has only PaX features, but no GRsecurity features? Also, if you have time, please try playing around with turning on/off various PaX features to try to find the ones which make a difference. I suggest starting with a kernel that has the PaX+GRsecurity patches, but configure all PaX and GRsecurity features to be disabled. If that works, add half of the PaX features that you have in one of the non-working profiles. Continue the binary search until you find the relevant feature or run out of time.

comsatcat wrote:That really just looks like the kernel panic and not info related to grsec.. hope this helps though.

so as expected, execve fails for init. the next thing to track down is where exactly that happens. my bet is on load_elf_binary in fs/binfmt_elf.c, so could you instrument that code with printk's before every possible error return and tell me which one fails (and possibly with some extra info about the failure condition, like requested mmap addresses, error code, etc)? if you need help with this, let me know and i'll cook up a patch. oh and please try 2.6.23, older kernels are no longer supported (you can backport the fix if it turns out to be simple, but let's do the debugging on this kernel please).

The issue with UML in fs/binfmt_elf.c is the line:

unsigned long /* ... */ task_size = TASK_SIZE;

In uml TASK_SIZE is defined to be:
#define TASK_SIZE (task_size)

This is because the task size can change depending on the host configuration dynamically at run time.

Simply doing a search and replace for task_size to task_sz in fs/binfmt_elf.c will likely fix the issue.

I've sent a patch for this to the PaX team (which includes a similar change in mremap.c). Thanks for the fix!

-Brad

jwessel wrote:Simply doing a search and replace for task_size to task_sz in fs/binfmt_elf.c will likely fix the issue.

thanks for the help everyone, i went with pax_task_size instead so as to avoid any future name collision.