Re: [vserver] Vserver + grsec thoughts

Ed, Rik, All,

> grep for "unchecked" in the kernel/verver subdirectory (of a vserver+grsec
> patch that i made before)... that will give you a list of "unchecked"
> atomic definitions, which means they don't cause a refcount overflow panic
> in the kernel (if you enabled refcount checking). But as i said, i'm not
> 100% sure that 's pax-stuff.

When PaX is prepared for mainline the PaX team switches vanilla atomic
reference counters to unchecked variants when overflow is expected,
all others are checked. You need to know which counters from the
Vserver patchset are susceptible to intentional overflowing so they
are exempted from the refcount checks PaX preforms.

As for the grsecurity patchset, I'd argue that there are a lot of
desirable features that do provide additional security to the
resulting kernel. Some examples:

1. CONFIG_GRKERNSEC_KMEM

This helps tamperproof kernel space by preventing known ways of
introducing code to the kernel

http://www.linuxjournal.com/magazine/anthony-lineberry-devmem-rootkits
http://lwn.net/Articles/328695/

2. CONFIG_GRKERNSEC_MODHARDEN

Having this setting would have prevented sock_sendpage and the more
recent rds kernel exploits from working correctly

http://www.grsecurity.net/~spender/wunderbar_emporium2.tgz
http://xorl.wordpress.com/2010/11/08/grsecuritys-grkernsec_modharden-protection-and-the-rds-local-root-exploit/

3. CONFIG_GRKERNSEC_HIDESYM

A lot of exploits bank on the fact that distros ship pre-built kernels
with known symbol tables (provided with package). The exploit simply
fingerprints the kernel and uses addresses gleaned from this
information, by compiling your own kernel and with hidden symbols it
really makes it a guessing game for the attacker.

4. CONFIG_GRKERNSEC_BRUTE

This complements #3, without a measure to prevent brute forcing #3
just slows attackers down.

I know it takes a considerable amount of work to maintain this
patchset and I'm not suggesting that you should/shouldn't do a
pax+vserver only kernel, I'm simply highlighting some features in
grsecurity that I see as desirable. I think dismissing the grsecurity
portion simply as access control and chroot hardening is a gross
oversimplification (I'm not suggesting that this was necessarily your
intent).

-- 
Kyle