7 ms·

Can someone explain why being in-kernel is considered a feature?

zx2c4 10y ago
Speed, simplicity. It's not possible to do highspeed crypto from userspace while still integrating with the usual networking stack. Tun devices result in copies and context switches which makes things quite slow. This also adds quite a bit of simplicity. But sure, I agree, it's scary. But not nearly as scary as the obscenely huge xfrm/ipsec layer in the kernel. Or the dozens of other kernel tunneling deivces available. And I dare even say it's not as scary as most userspace VPN solutions like OpenVPN which are massive code bases. WireGuard, in contrast, aims to be quite minimal in its codebase, so that it can be audited by an individual. I didn't make the title of this HN post, unfortunately. But do note: there _will_ be userspace implementations of WireGuard. It's most certainly not tied to the kernel. It's just that the OP saw me present at a kernel conf about it. :P
nickpsecurity 10y ago
It's faster. Performance usually matters more than security for most "security" products. ;) Having extra code in kernel is usually just asking for it. Here's one done closer to high-assurance principles that I'm sure the WireGuard scheme could be ported to: http://genode-labs.com/publications/mikro-sina-2005.pdf http://genode-labs.com/publications/mikro-sina-2005.pdf Far as keeping it in kernel, it might be implemented in SPARK and Rust to see if it gets through static and dynamic (if necessary) checkers. Test and fuzz it heavily. If C, use strong, static tools to show correctness and/or compiler transformations like SAFEcode (or Softbound+CETS) to immunize it. I know Criswell runs Linux kernel on SVA-OS with SAFEcode but not sure if S+CETS can do it. Such approaches will knock out most of the flaws that lead to code injection.
- zx2c4 10y ago
  We'll actually be producing a Rust implementation for userspace. It'd be interesting to see that work ported back to kernelspace. Cool suggestions.
  - nickpsecurity 10y ago
    That sounds good. What's its current implementation language?
    - tptacek 10y ago
      It's Linux kernel resident. It's C code.
      - nickpsecurity 10y ago
        Wow. Talk about overlooking the obvious. Thanks lol...
        viraptor 10y ago
        Maybe most likely, but not necessarily obvious. While there's no popular module for kernel written in something else than C (as far as I know), there are known ways to write working non-C modules.
        nickpsecurity 10y ago
        C was best assumption as 99+% chance it would be C. Yet, you are right in that I've seen device drivers for Linux done in Ada and ATS languages. It's why I usually don't assume but one was warranter here.
artie_effim 10y ago
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.
- tptacek 10y ago
  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.
  - Retr0spectrum 10y ago
    "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?
    - tptacek 10y ago
      Start here: https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-ROP.pdf 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.

zx2c4 10y ago

Speed, simplicity. It's not possible to do highspeed crypto from userspace while still integrating with the usual networking stack. Tun devices result in copies and context switches which makes things quite slow. This also adds quite a bit of simplicity. But sure, I agree, it's scary. But not nearly as scary as the obscenely huge xfrm/ipsec layer in the kernel. Or the dozens of other kernel tunneling deivces available. And I dare even say it's not as scary as most userspace VPN solutions like OpenVPN which are massive code bases. WireGuard, in contrast, aims to be quite minimal in its codebase, so that it can be audited by an individual. I didn't make the title of this HN post, unfortunately. But do note: there _will_ be userspace implementations of WireGuard. It's most certainly not tied to the kernel. It's just that the OP saw me present at a kernel conf about it. :P

nickpsecurity 10y ago

It's faster. Performance usually matters more than security for most "security" products. ;) Having extra code in kernel is usually just asking for it. Here's one done closer to high-assurance principles that I'm sure the WireGuard scheme could be ported to: http://genode-labs.com/publications/mikro-sina-2005.pdf http://genode-labs.com/publications/mikro-sina-2005.pdf Far as keeping it in kernel, it might be implemented in SPARK and Rust to see if it gets through static and dynamic (if necessary) checkers. Test and fuzz it heavily. If C, use strong, static tools to show correctness and/or compiler transformations like SAFEcode (or Softbound+CETS) to immunize it. I know Criswell runs Linux kernel on SVA-OS with SAFEcode but not sure if S+CETS can do it. Such approaches will knock out most of the flaws that lead to code injection.

zx2c4 10y ago
We'll actually be producing a Rust implementation for userspace. It'd be interesting to see that work ported back to kernelspace. Cool suggestions.
- nickpsecurity 10y ago
  That sounds good. What's its current implementation language?
  - tptacek 10y ago
    It's Linux kernel resident. It's C code.
    - nickpsecurity 10y ago
      Wow. Talk about overlooking the obvious. Thanks lol...
      - viraptor 10y ago
        Maybe most likely, but not necessarily obvious. While there's no popular module for kernel written in something else than C (as far as I know), there are known ways to write working non-C modules.
        nickpsecurity 10y ago
        C was best assumption as 99+% chance it would be C. Yet, you are right in that I've seen device drivers for Linux done in Ada and ATS languages. It's why I usually don't assume but one was warranter here.

artie_effim 10y ago

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.

tptacek 10y ago
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.
- Retr0spectrum 10y ago
  "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?
  - tptacek 10y ago
    Start here: https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-ROP.pdf 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.