Security Level (High) with Kernel 2.6.19.2

[am]

I patched the kernel 2.6.19.2 with the grsecurity patch.
I enabled the option "Security Level (High)" without any other grsec option.
When I boot this kernel, it hangs with
---snip---
grsec: signal 11 send to /sbin/init[init:1] uid/euid :0/0 gid/eid :0/0,
parent /[swapper :0] uid/euid :0/0 gid/edid :0/0
---snip---

Distribution is debian sarge.
Which grsec option cause this.
Is there a problem in the init command?
If I try "Security Level (Medium)" it is working, but I would enable "Security
Level (High)"

THX for all answers
Andreas

[systray`]

Hi,

I've the same Problem I think: http://forums.grsecurity.net/viewtopic.php?t=1694
But it's my remote Maschine and I can't see where my kernel hangs!
Hope for an answer too.

Cheers.

[Alexei.Sheplyakov]

I've the same Problem I think: http://forums.grsecurity.net/viewtopic.php?t=1694
But it's my remote Maschine and I can't see where my kernel hangs!

How do you know if it is the same or not if you haven't seen any
logs?

Hope for an answer too.

Are you serious? How can one debug/fix your problem without any info
at all? What about your .config, glibc version, etc.? Have you tried
to capture logs via netconsole?

[systray`]

I don't KNOW if it's the same, but I THINK.

It's the same on my maschine, if I set grsecurity to *HIGH*, then my Kernel don't boot, that's all I know.

My Config with Grsec MEDIUM: http://webspace.ms/config
My Config with Grsec HIGH: http://webspace.ms/config2

I'm using gcc 4.1.2 and glibc version 2.3.6

Cheers.

[Alexei.Sheplyakov]

I patched the kernel 2.6.19.2 with the grsecurity patch.
I enabled the option "Security Level (High)" without any other grsec option.
When I boot this kernel, it hangs with

---snip---
grsec: signal 11 send to /sbin/init[init:1] uid/euid :0/0 gid/eid :0/0,
parent /[swapper :0] uid/euid :0/0 gid/edid :0/0
---snip---

Technically, your description is not exactly incorrect: the kernel did
not "hang", it killed init (which presumably was trying to do something
weird).

Distribution is debian sarge.

I've got a sarge chroot (used as buildd) on my x86 etch box running
2.6.19.2, it works just fine. The .config is available at
<http://theor.jinr.ru/~varg/web/linux/config-2.6.19.2-grsec-p4-smp>

Which grsec option cause this.

This is not necessary some "grsec option" caused this. Anyway, according
to grsecurity/Kconfig, the difference between "Security Level (High)"
(GRKERNSEC_HIGH) and "Security Level (Medium)" is the following:

Code: Select all

select GRKERNSEC_LINK
select GRKERNSEC_FIFO
select GRKERNSEC_EXECVE
select GRKERNSEC_DMESG
select GRKERNSEC_FORKFAIL
select GRKERNSEC_TIME
select GRKERNSEC_SIGNAL
select GRKERNSEC_CHROOT_SHMAT
select GRKERNSEC_CHROOT_UNIX
select GRKERNSEC_CHROOT_MOUNT
select GRKERNSEC_CHROOT_FCHDIR
select GRKERNSEC_CHROOT_PIVOT
select GRKERNSEC_CHROOT_DOUBLE
select GRKERNSEC_CHROOT_CHDIR
select GRKERNSEC_CHROOT_MKNOD
select GRKERNSEC_CHROOT_CAPS
select GRKERNSEC_CHROOT_SYSCTL
select GRKERNSEC_CHROOT_FINDTASK
select GRKERNSEC_PROC
select GRKERNSEC_PROC_MEMMAP if (PAX_NOEXEC || PAX_ASLR)
select GRKERNSEC_HIDESYM
select GRKERNSEC_BRUTE
select GRKERNSEC_SHM if (SYSVIPC)
select GRKERNSEC_PROC_USERGROUP
select GRKERNSEC_KMEM
select GRKERNSEC_RESLOG
select GRKERNSEC_RANDNET
select GRKERNSEC_PROC_ADD
select GRKERNSEC_CHROOT_CHMOD
select GRKERNSEC_CHROOT_NICE
select GRKERNSEC_AUDIT_MOUNT
select GRKERNSEC_MODSTOP if (MODULES)
select PAX_NOEXEC
select PAX_MPROTECT
select PAX_EI_PAX
select PAX_PT_PAX_FLAGS
select PAX_HAVE_ACL_FLAGS
select PAX_KERNEXEC if (!X86_64 && !MODULES && !HOTPLUG_PCI_COMPAQ_NVRAM && !PCI_BIOS)
select PAX_RANDKSTACK if (X86_TSC && !X86_64)
select PAX_SEGMEXEC if (X86 && !X86_64)
select PAX_PAGEEXEC if (!X86)
select PAX_EMUPLT if (ALPHA || PARISC || PPC32 || SPARC32 || SPARC64)
select PAX_DLRESOLVE if (SPARC32 || SPARC64)
select PAX_SYSCALL if (PPC32)
select PAX_EMUTRAMP if (PARISC)
select PAX_EMUSIGRT if (PARISC)
select PAX_ETEXECRELOCS if (ALPHA || IA64 || PARISC)


In my config I have almost all of these (leaving aside arch-dependent
work-arounds) switched on too, _except_

Code: Select all

GRKERNSEC_PROC_MEMMAP
GRKERNSEC_FORKFAIL
PAX_RANDKSTACK


So one of these 3 _MIGHT_ make your kernel to kill init. There are
some more options I use -- TPE, socket restrictions, etc., but I don't
think they are relevant here.

Is there a problem in the init command?

Install busybox-static and try to boot with init=/bin/busybox to check

If I try "Security Level (Medium)" it is working, but I would enable
"Security Level (High)"

It is not a silver bullet :) Anyway, you might take the config from
"Security Level (Medium)" and enable different options selected by
"Security Level (High)" one-by-one. Or the other way around: manually
select every option that "Security Level (High)" selects, and switch
them off one-by-one. Those 3 options I've mentioned previously might
be good candidates to start with...

[Alexei.Sheplyakov]

if I set grsecurity to *HIGH*, then my Kernel don't boot, that's all I know.

How do you know if this is _kernel_ failure (as opposed to some
user-space program doing something wrong and thus getting killed)?

My Config with Grsec MEDIUM: http://webspace.ms/config

You haven't mentioned that you can boot with "Security Level (Medium)".

My Config with Grsec HIGH: http://webspace.ms/config2

I'm using gcc 4.1.2 and glibc version 2.3.6

Recompile your kernel with CONFIG_COMPAT_VDSO switched off.

Good luck!

[systray`]

Hi,

That was it.
I looked a bit around and I found this one:

http://www.ussg.iu.edu/hypermail/linux/ ... /1482.html

Is it this bug?

Cheers.

[am]

I recompiled the kernel without CONFIG_COMPAT_VDSO.
The kernel boot without any problems.

Thanks!!!!!
Andreas

[Alexei.Sheplyakov]

I looked a bit around and I found this one:

http://www.ussg.iu.edu/hypermail/linux/ ... /1482.html

Is it this bug?

AFAIK COMPAT_VDSO defeats some randomization features of PAX, so one
should switch it off anyway. In fact, older versions of grsec (including
previous one) used to disable VDSO completely. In recent kernels
(>= 2.6.19 ?) VDSO is not mapped at fixed address any more. But older
glibc (< 2.3.3) can not cope with it, hence CONFIG_COMPAT_VDSO option.
And it is on by default (Linux kernel folks do not care very
much about security, but they do care about binary compatibility).

I think grsec patch should disable COMPAT_VDSO (at least when address
space randomization and is used).

[PaX Team]

AFAIK COMPAT_VDSO defeats some randomization features of PAX, so one
should switch it off anyway.

COMPAT_VDSO is incompatible with more important features (check the dependencies in security/Kconfig), so lack of (some) randomization is the least of your problems .

In fact, older versions of grsec (including previous one) used to disable VDSO completely.

indeed, because it was at a fixed address and couldn't be as easily randomized as other mappings.

I think grsec patch should disable COMPAT_VDSO (at least when address
space randomization and is used).

check the chunk applied to arch/i386/Kconfig, it defaults to 'n' under PaX, maybe defconfig should be changed too though.

[Alexei.Sheplyakov]

check the chunk applied to arch/i386/Kconfig, it defaults to 'n' under PaX,
maybe defconfig should be changed too though.

I'm aware of that. But somehow people end up with both PAX_SEGMEXEC
and COMPAT_VDSO switched on. So I think grsec/PAX should not offer
COMPAT_VDSO option at all. Ideally, the actual code which implements
it should be disabled too (#if ! defined(PAX_NOEXEC) or even #if 0).

[PaX Team]

But somehow people end up with both PAX_SEGMEXEC and COMPAT_VDSO switched on.

yes, that's the actual problem but i haven't looked into it yet, patches or ideas are welcome .