Start here:

https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-ROP.p...

Are you running the grsecurity patches? If not, everything they do that your kernel doesn't do is another reason your userland will inevitably cough your kernel up to an attacker at some point. Even with those patches, it's still an inevitability; it's just that interval is longer.

I don't run them! I do something easier: I assume that if I lose control of userland on a Linux machine, I've lost the whole box.

It is especially weird, though, to see security people engaging in this kind of risk reasoning. It seems to me that most of the times you lose code execution on your VPN server, the kernel security of the VPN server is pretty far down the list of problems you need to deal with.

For an alternative view, having the apps in user-mode with mandatory controls and such has isolated many real-world vulnerabilities. Even in the shoddy, inadequate implementation that is SELinux. Further, as attackers are battling constraints, they increase odds of generating logs that detect their presence via the unauthorized behaviors. There's also products and prototypes that constantly read memory to find anomolous patterns that depend on kernel or hypervisor layer integrity. The protections get even stronger if using microkernel, capability, pointer, or tainting protection.

So, despite severity of VPN-level compromise, there's advantages mainly in detection and damage limitations if it's a strongly-constrained process. Hell, I've done prototypes that used fixed memory with only networking privileges needed that logged their own behavior to immutable storage. You could compare the execution and logging to a profile. Outside that range, it was a crash or attack. Clive Robinson taught me that last part. Others were Orange and Red Book 101.