So, everyone needs to take a deep breath here. In kernel VPN is giving me a bit of a security heart attack. As a security professional I would recommend not running this on anything but a sandbox that isn't connected to your environment. A single misstep in the code, a bad implementation of a crypto library or a bad hook could easily lead to ring 0 compromise.
Not trying to discount the author's work, and I haven't reviewed any of the documentation, but until this gets evaluated by a CC lab (or like independent group) I would not implement in anything you care about.
As a "security professional", I kind of don't care whether this is in-kernel or not.
First, this is Linux, and if someone manages to get code execution in your unprivileged userland program, the odds of you keeping them out of your kernel are already pretty low.
Second, and more importantly, this is VPN software. If your VPN gets popped, you probably have bigger problems than whether the attacker got the kernel on the VPN server, as opposed to just being able to create arbitrary network connections from the "inside" of the VPN.
If you don't want to run it, don't run it. If you're going to ask me whether I'd trust OpenVPN more than WireGuard, no, I do not.
What do you want me to say? I'd think it ought to be self-evident that greater risks exist when operating in a single shared memory space at ring 0. If nothing else, the trampoline to privilege is already complete; very little stands between a vulnerability and an active exploit.
The end goal ought to be getting more things out-of-ring 0, not adding more things to it -- I'm never going to say that "I'm not concerned" or that "It's a non-issue" (although I will say that I'm a lot more worried about the massive amounts of crap code in WiFi drivers than I am about a VPN implementation, generally speaking).
In the OpenVPN case, numerous vulnerabilities have been limited to only DoS exploits due to the zealous use of assert(); in the kernel case, that brings down your machine, and quite often, assertions are compiled out of the release kernel due to their overhead in critical paths (whether they should be is another question).
netmap is a framework for extremely fast and efficient packet I/O for
both userspace and kernel clients. It runs on FreeBSD and Linux, and
includes VALE, a very fast and modular in-kernel software switch/data-
plane, and netmap pipes, a shared memory packet transport channel. All
these are accessed interchangeably with the same API.
netmap, VALE and netmap pipes are at least one order of magnitude faster
than standard OS mechanisms (sockets, bpf, tun/tap interfaces, native
switches, pipes), reaching 14.88 million packets per second (Mpps) with
much less than one core on a 10 Gbit NIC, about 20 Mpps per core for VALE
ports, and over 100 Mpps for netmap pipes.
Userspace clients can dynamically switch NICs into netmap mode and send
and receive raw packets through memory mapped buffers. Similarly, VALE
switch instances and ports, and netmap pipes can be created dynamically,
providing high speed packet I/O between processes, virtual machines, NICs
and the host stack.
It's possible to shake off OpenVPN and TLS without shaking off use of tun/tap. I use a tun/tap based "VPN" (overlay) and I quite like it. One could even add NaCl to it if they were so inclined.
I sometimes think Apple removed /dev/tap from iOS because it provided too much potential freedom.
Not every user needs in-kernel performance for their daily routine but there's certainly an argument that every user could use a decent "VPN" that could run on all their computers.
Alas, OpenVPN mindshare is rather strong, to the detriment of existing or future userspace alternatives.
I'm curious, you don't agree that the complexity of an access vuln + privesc vuln is a better defender position than a single vuln to ring-0?
It kind of seems to fly in the face of the multiple layers of userland and kernel separation engineering we've seen go into other attack surfaces like browsers?
All things being equal I do think it's better to be in the former position than the latter.
But all things are not equal. Any code execution on the VPN server practically implies that the attacker controls the VPN, which is game-over for most VPNs I've ever worked with. So my priority would be "not having those kinds of vulnerabilities at all". I'd rather have simpler, easier-to-audit code than userland, if I have to choose one.
"If someone manages to get code execution in your
unprivileged userland program, the odds of you keeping
them out of your kernel are already pretty low."
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.
> In kernel VPN is giving me a bit of a security heart attack.
You may be surprised, then, that most of the standard VPN tech — IPsec, GRE+PPTP, VxLAN, etc. — operate in the kernel (with some help from userland apps for things like IKE).
I'm referring to Linux, where the implementations of those protocols are kernel modules. There are user-space implementations, of course, such as Rockhopper (IPsec). But they're not performant.
Not trying to discount the author's work, and I haven't reviewed any of the documentation, but until this gets evaluated by a CC lab (or like independent group) I would not implement in anything you care about.