[grsec] grsecurity & lguest

[pageexec at freemail.hu]

On 2 Nov 2010 at 0:01, Philip Sanderson wrote:

hey,

someone with too much time on his hands ;). seriously, i'm surprised that
lguest even compiles, let alone boots, so if you feel like fixing it up
for good, you're welcome to send your changes in.

> Mostly good news, lguest works using PAGEEXEC for the host, and SEGMEXEC for
> the guests (lguest does not support NX bit, as documented in
> arch/x86/lguest/boot.c, so it falls back.) UDEREF works from what I can
> tell.

it's easy to test it with any recent/decent kernel exploit du jour (check the
host first ;).

> Commenting out the line that disables NX bit and recompiling makes it use
> page exec, but paxtest exec tests fail. It would be ideal if lguest
> supported NX bit. I have not looked at why this is the case, or how easy it
> would be to implement it.

given that lguest supports guest PAE from what i see, it should be easy to
fix the NX situation. probably the bit gets lost somewhere so you should
add some debug code into the pte manipulating paravirt ops and see what
happens.

> KERNEXEC seems like it would be unsupported; as lguest wants to map
> executable code at 0xff[ce]00000 (drivers/lguest/core.c). I know for certain
> it does not work if you enable kernel modules :-) It would be nice if it was
> supported for the host. From looking at free_initmem(), it won't be
> supported if it is being paravirt'd.

uhm, KERNEXEC is explicitly weakened to allow the 'world switch' style code
used under other paravirtualized systems such as vmware (the CS limit basically
covers the entire kernel virtual address space). however that is only half of
the story, all code passing/using function pointers must be carefully audited
and logical/linear translations added as necessary (ktla_ktva/ktva_ktla macros).
in fact most of the time the kernel will oops when such a translation is missing,
so it's not hard to find these places.

> A random thought is that by tweaking KERNEXEC to prevent userland access
> (yet allow full kernel) and relying on PAE+NX (to protect kernel pages) will
> give you at least something on the host kernel while allowing lguest to
> work. that said, it could be argued that having that mapped in memory at a
> fixed location is a bad idea.

known code at a fixed address is not a new problem since you already have it
with vmlinux already (especially on a distro kernel). the above mentioned CS
limit relaxation effectively means that the host kernel does rely on NX (when
in PAE mode obviously) to protect the kernel address space, but i didn't do
a full audit as i did on amd64, so it's possible that some pages outside of
the kernel/module text area are left as rwx (kmaps should help you there).