121–130 of 133 posts
Earlier quoted context omitted.
What do you think are the current problems contributing to your slow transfers?
Window and buffer size is a problem on high latency links.
Earlier quoted context omitted.
Sorta? If it renders them moot, why not attack the policies? For that matter, if there are no implications to the number of the port, I'm again forced to ask why not just use the higher numbers? Wouldn't that have let you use the "simplicity of standard socket code" with no extra effort? (This is also a new use of "moot" to me? You seem to be offering it as a synonym of obsolete? But a "moot" debate is one that is cl…
You get that these are just people shipping a program that random people are going to run on random computers, right? If your go-to-market involves "reversing longstanding Unix network policy rules", you have problems. Respectfully, if at this point the situation hasn't been made clear to you, I don't think there's much more to productively discuss.
My impression from something said elsewhere was that this was largely for internal tools. I'm not sure why I got that impression, though.
I think it is fair, btw, that I would be pushing for both paths, at this point? If a long standing network policy rule has become obsolete from advance, it is worth considering dropping it? Is that not something people are looking at?
(I will also note that I will not be at all offended if you drop out from lack of interest here. Apologies if you feel I was wasting your time!)
Earlier quoted context omitted.
How is it more portable or secure than an API that's been stable for decades, and getting constant security fixes? I see an explanation in their blog about avoiding TUN devices since they require elevated permissions, but why would you need a TUN device to send data to/from an application? I can't understand what their product does from the marketing material but it doesn't look like it would require constructing raw…
You can have multiple layers of security boundary on most of the customer-exposed surface area, and avoid more risky surface areas in the kernel. Portable is a bit of a weird word here because for many of us with gray beards the word means architectures, kernels and systems, but I think in this context it tends to more mean "can run just as easily on my macbook as in a cloud container", but in practice the software i…
I fail to see what "risky surface areas" in the kernel you're avoiding. You have more packets going through the kernel network stack(since you're wrapping a TCP connecting in a UDP connection that goes through the kernel) than just using the TCP stack in the kernel. Are you saying that the TCP stack in the kernel cannot be trusted, but a userspace kernel you maintain can(that's a bit ridiculous...)
> can run just as easily on my macbook as in a cloud container
Any POSIX C code that listens on non-privileged ports will run on machines with the correct glibc version(and you can statically compile the glibc or not need it like go does). This includes linux and macOS(and if you're using a library that's on multiple OSes you get even more support without having to implement TCP in userspace).
> Constant security fixes for the kernel are a real pain in deployments unless you follow upstream kernels closely.
I don't think you understand. You're still at the mercy of the kernel for security patches to the UDP stack, you're just now also having to maintain a TCP stack in parallel.
> An alternative approach might be firecracker / microvms and so on
Wouldn't an alternative approach just be to use cross-platform libraries and non-privileged ports?
> The core point is that you want more than one layer between the host machines and the user code that wants to interact with Linux features.
You just said the opposite... how can more things requiring security fixes be a bad thing, while you arbitrarily want more layers between you and the most security tested code for networking available to you.
Earlier quoted context omitted.
I don't think you understand, and based on your reply it doesn't sound like I'm mistaken. With this CLI I am able to listen for external packets to port 80 from userspace without any elevated permissions and intercept traffic that's going to an application that's bound to that port on the OS? Edit: I think I understand what you're trying to do, but if I do then traffic is going from the kernel UDP stack to the userla…
I'm not sure I can make this any simpler for you or easier to get your head around. If it helps: the idea here is giving an invocation of your program its own IP address . It can then do whatever it likes with TCP/IP for that address; its own routing, arbitrary protocols, whatever. The Go standard library makes it extremely easy to integrate. To the OS, it's all just ordinary socket code.
I understand that, I just don't understand any case where that's desirable...
We have 2^32 ports available to applications(and a special `0` port that can be used to request any port) on a single IP(which is usually shared between multiple machines). I have never heard of a case where 2^32 ports is not enough ports for the number of applications that need to be listening.
> To the OS, it's all just ordinary socket code.
Which is what I don't understand. Why not just use ordinary socket code without all of these additional LoC in between that open you up to more bugs(security and functionality).
Earlier quoted context omitted.
Right... but that just seems to imply that this is getting around policies by the letter? I should hasten to add that I am not offering this as reason this shouldn't be done.
I know this is subtle but if you take a step back, user-mode TCP/IP moots the policies we're talking about; it doesn't subvert them. There are no security or policy implications to e.g. binding a low-numbered port on an IP address unrelated to your physical computer that is allocated directly to a running instance of your program. There are (archaic) implications to binding that port on an actual interface of your ma…
Earlier quoted context omitted.
If you're talking about developer machines, isn't the best(and easiest) solution to just run a VM that you administer so you can create virtual networks? If you're talking about production machines, a userspace application wouldn't be able to sniff privileged ports without elevated permissions, so I fail to see how this application would let you get around that limitation.
No, because VMs are expensive and require some base level of system administration to operate, booting them usually requires privilege, and if the only problem you're trying to solve is reliably running (e.g.) Postgres and Redis protocol between your CLI and a server somewhere, it's extreme overkill.
Postgres and Redis can use non-privileged ports, so I don't understand why this would matter.
Earlier quoted context omitted.
I know this is subtle but if you take a step back, user-mode TCP/IP moots the policies we're talking about; it doesn't subvert them. There are no security or policy implications to e.g. binding a low-numbered port on an IP address unrelated to your physical computer that is allocated directly to a running instance of your program. There are (archaic) implications to binding that port on an actual interface of your ma…
Doesn't this program need to bind a UDP port on your machine? If policies prevent you binding ports I don't see how you'd be able to use this software...
Earlier quoted context omitted.
No, because VMs are expensive and require some base level of system administration to operate, booting them usually requires privilege, and if the only problem you're trying to solve is reliably running (e.g.) Postgres and Redis protocol between your CLI and a server somewhere, it's extreme overkill.
VMs are free and can be run by any semi-competent developer wanting to host a test server on their development machine. Postgres and Redis can use non-privileged ports, so I don't understand why this would matter.
Earlier quoted context omitted.
You can have multiple layers of security boundary on most of the customer-exposed surface area, and avoid more risky surface areas in the kernel. Portable is a bit of a weird word here because for many of us with gray beards the word means architectures, kernels and systems, but I think in this context it tends to more mean "can run just as easily on my macbook as in a cloud container", but in practice the software i…
> You can have multiple layers of security boundary on most of the customer-exposed surface area, and avoid more risky surface areas in the kernel. I fail to see what "risky surface areas" in the kernel you're avoiding. You have more packets going through the kernel network stack(since you're wrapping a TCP connecting in a UDP connection that goes through the kernel) than just using the TCP stack in the kernel. Are y…
Yes that’s exactly right. It’s not ridiculous. Netstack is written in a GC’d language which alone eliminates several categories of vulnerabilities that exist in the kernel. But more important than that is that it’s in USERSPACE. So even if you do compromise gVisor netstack the best you have is the capabilities that any other normal process has. Compare that to the kernel vulnerabilities where you potentially have cracked root.
> You're still at the mercy of the kernel for security patches to the UDP stack, you're just now also having to maintain a TCP stack in parallel.
The TCP stack is at least an order of magnitude more complex than UDP and has a correspondingly much higher number of bugs filed against it. Only relying on UDP is a security win.
Earlier quoted context omitted.
Every connection you make to a remote service "exfiltrates data". Modern TLS is just as opaque to middleboxes as WireGuard is, unless you add security telemetry directly to endpoints --- and then you don't care about the network anyways, so just monitor the endpoint. The reason you'd use WireGuard rather than TLS is that it allows you to talk directly to multiple services, using multiple protocols (most notably, thin…
Adding your own network stack to bypass limitations like this works exactly until the point where someone notices that your userspace stack needs to fulfill the same requirements that the host stack does. And then you're suddenly in a whole world of pain because all of this is driven by a stack of byzantine certifications (half of which, as usual, are bogus, but that doesn't help you), and your network stack has none…