Why is this in the kernel? It seems to me like a failed separation of concerns compared to running this in userspace. There shouldnt be anything magical requiring this level of coupling.
WireGuard: next generation in-kernel modern VPN
41–50 of 157 posts
Re: WireGuard: next generation in-kernel modern VPN
#42Can someone explain why being in-kernel is considered a feature?
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.
Re: WireGuard: next generation in-kernel modern VPN
#43Why is this in the kernel? It seems to me like a failed separation of concerns compared to running this in userspace. There shouldnt be anything magical requiring this level of coupling.
Severe performance impact.
Since we appear to be bolted to the top of the thread, I'll repeat a point I buried deeper in the thread:
Maybe some readers of this thread are in the habit of casually bringing up random VPN connections between individual Linux machines. But in my experience, people tend to invest in VPN configurations so they can connect developers and ops to deployment environments and company networks. That's like, the big use case for serious VPNs.
In a serious VPN deployment, if you lose code execution on the VPN server, whether the attacker took the kernel or just a userland process is somewhat far down the list of concerns you have to deal with. A better first concern is "how many machines inside the VPN did the attacker just get code execution on because they can now make direct TCP connections to all our internal services".
From that vantage point, I'm a little less concerned about whether my VPN server is at CPL0, and a lot more concerned with things like "how complex is this code and how straightforward is it to audit".
Re: WireGuard: next generation in-kernel modern VPN
#44Can someone explain why being in-kernel is considered a feature?
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 r…
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.
Re: WireGuard: next generation in-kernel modern VPN
#45Earlier quoted context omitted.
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 r…
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 t…
"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."
Re: WireGuard: next generation in-kernel modern VPN
#46Earlier quoted context omitted.
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 t…
"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." Could you provide some sources/examples for this?
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.
Re: WireGuard: next generation in-kernel modern VPN
#47Earlier quoted context omitted.
Thanks for being here, I have a few questions. Does the server get a separate wg interface for every client that connects? Or does it do something like multipoint GRE interfaces with next hop addresses in the arp table? Does this do a DH key agreement to guarantee forward secrecy or does it literally encrypt the packet with the peers public key? Also is it in the scope of this project for peers to discover each other…
> Does the server get a separate wg interface for every client that connects? No. Each wg interface has a public/private key. It then has a list of peers' public keys and associated allowed IPs. By tying each public key to the allowed IPs of that public key, you can be sure that if a packet comes from wg0 and comes from a particular src IP, it comes from who you want. So no need for a new wg0 for each peer. > Does th…
DMVPN capability would be outstanding and would make WireGuard much more useful in a AWS VPN situation. This video from the 2015 AWS re:Invent [0] conference has an overview of DMVPN and how it could be used in a AWS VPC.
Re: WireGuard: next generation in-kernel modern VPN
#48Wow, I launched this 10 minutes ago and somebody already put it on Hacker News. Spectacular! I'm the author of this and would be happy to answer any questions you have.
Any chance of switching to a non-GPLv2 license? Broad adoption would be far more likely.
Re: WireGuard: next generation in-kernel modern VPN
#49Earlier quoted context omitted.
I don't really have any problem re-licensing it less restrictively, I don't think. I'll have to think about it for more than 10 seconds I suppose. But I put "GPLv2" there without much thought simply because that's what Linux uses. But you make a good point about the BSDs.
As a hardcore BSD user, GPLv2 is perfectly fine with the BSDs. They all ship with GPLv2 software by default. FreeBSD doesn't like GPLv3, but OpenBSD and DragonFlyBSD don't have a problem with it. I don't know about NetBSD off the top of my head. IMO this seems like something that should be GPL and I think you needn't change it.
GPLv2 doesn't work for in-kernel code, or for code that could be used as a library.
Re: WireGuard: next generation in-kernel modern VPN
#50Earlier quoted context omitted.
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 r…
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 t…
> As a "security professional", I kind of don't care whether this is in-kernel or not.
As a "kernel professional", I'm laughing incredulously at this. A lot.