5 ms·

They are exactly the same situation. When you run other people's code you are explicitly giving them control over your stuff. Ken Thompson pointed this out back

by ukj 5y ago

They are exactly the same situation. When you run other people's code you are explicitly giving them control over your stuff. Ken Thompson pointed this out back in 1984. ( https://dl.acm.org/doi/pdf/10.1145/1283920.1283940 https://dl.acm.org/doi/pdf/10.1145/1283920.1283940 ) Either you trust the entity whose code you are consuming or you don't. Do you trust WireGuard to not get owned via a supply chain attack? Like Solar Winds. Do you trust any open source project you currently use to be free from bugdoors? Like University of Minnesota recently demonstrated by submitting intentionally-vulnerable patches to the Linux kernel.

jerf 5y ago
There a significant difference. When I run code, it is isolated from the people who wrote it. Someone providing a github library I compile into my code has no ability to later unilaterally come in and modify it. There is a gate where I have to ask them in, and I do tend to read the diffs first. There are only isolated windows of temporal vulnerability where I have to trust them, with mechanisms for dealing with that coherently. An always-on service is an ongoing, continuous trust relationship with continuous temporal vulnerability Consequently, while I can reasonably safely apply a lower bar of trust to libraries and code, someone asking to be continuously trusted must be held to a distinctly higher standard. It is can be valid to trust that as well, but you're operating from a crippled starting point for your security engineering if you don't see those as separate categories of issues to address.
- ukj 5y ago
  >I do tend to read the diffs first. You are lying to yourself. You are necessarily claiming that a single person (you) is capable of adequately verifying the trustworthiness of the work of hundreds (perhaps even thousands) of developers. That's just the story you tell yourself to convince yourself that you are in control. Mean while FAANG have been doing it all wrong by hiring thousands of security engineers. They should've hired you.
- ukj 5y ago
  >Consequently, while I can reasonably safely apply a lower bar of trust to libraries and code, someone asking to be continuously trusted must be held to a distinctly higher standard. Also, this seems backwards to me. You trust Tailscale at the network layer. If they abuse your trust to inject routes/keys your machine becomes network-reachable but all of your other controls are still in tact. That's not true when you applications violate trust. You can do AppSec if you don't trust the network. You can't to NetSec if you don't trust the application.

by ukj 5y ago

jerf 5y ago

There a significant difference. When I run code, it is isolated from the people who wrote it. Someone providing a github library I compile into my code has no ability to later unilaterally come in and modify it. There is a gate where I have to ask them in, and I do tend to read the diffs first. There are only isolated windows of temporal vulnerability where I have to trust them, with mechanisms for dealing with that coherently. An always-on service is an ongoing, continuous trust relationship with continuous temporal vulnerability Consequently, while I can reasonably safely apply a lower bar of trust to libraries and code, someone asking to be continuously trusted must be held to a distinctly higher standard. It is can be valid to trust that as well, but you're operating from a crippled starting point for your security engineering if you don't see those as separate categories of issues to address.

ukj 5y ago
>I do tend to read the diffs first. You are lying to yourself. You are necessarily claiming that a single person (you) is capable of adequately verifying the trustworthiness of the work of hundreds (perhaps even thousands) of developers. That's just the story you tell yourself to convince yourself that you are in control. Mean while FAANG have been doing it all wrong by hiring thousands of security engineers. They should've hired you.
ukj 5y ago
>Consequently, while I can reasonably safely apply a lower bar of trust to libraries and code, someone asking to be continuously trusted must be held to a distinctly higher standard. Also, this seems backwards to me. You trust Tailscale at the network layer. If they abuse your trust to inject routes/keys your machine becomes network-reachable but all of your other controls are still in tact. That's not true when you applications violate trust. You can do AppSec if you don't trust the network. You can't to NetSec if you don't trust the application.