4 ms·

> Are you in control of your network connection? Packets aren't that much different from calls between DSOs. The difference is that calls between dynamic libra

by cesarb 7y ago

> Are you in control of your network connection? Packets aren't that much different from calls between DSOs. The difference is that calls between dynamic libraries are on the same side of the "airtight hatchway" (as explained by Raymond Chen at https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31283 https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...), while there's a security boundary at the network connection.

jart 7y ago
Imagine the modern PC as being just another substrate of this great battlefield where big corporations duke it out with each other and the individual owners are becoming less and less relevant to the security story. It's unpleasant. It seems to get raunchier each year. I've even seen household names retool things like graphics drivers to inject data harvesting code into command-line programs at runtime. Then the big companies who don't play dirty like that, usually react by demanding greater authoritarianism in tools, until the rest of us devs find ourselves smothered with -fpic aslr retpoline code-signed bubblewrapping, which isn't so much keeping us safe, but rather keeping big company A safe from big company B. Everything that the guy you linked said is correct. But locks aren't that relevant anymore, once the wolves have been invited in to live.
- quotemstr 7y ago
  You've used a lot of rhetoric, but you haven't described a threat model. Both this comment and your previous one, the GP, use language of moral duty when talking about a specific software security measure. That's a category error. What specific threat is bypassing libc supposed to protect against? I don't think you have an argument here. As the poster to whom you're replying mentioned, anyone who can do symbol interposition already has full control over your program.
  - jart 7y ago
    Perhaps you could share specific details on the use cases that dynamic symbol interposition is intended to serve? Because the only one I think I've seen so far is setbuf(1) and I can imagine more than a few alternatives that could have been considered.
    - quotemstr 7y ago
      Enumerating specific interposition user cases has nothing to do with the point I made, which is about threat modeling. You still have not articulated any specific threat model; you've instead tried to distract the conversation and move it in a different direction.
      - jart 7y ago
        You're welcome to complain about how I talk, but this isn't about me. This is about serving the user and making sure tech behaves the way they expect it to. We need to raise awareness of infrastructural weaknesses that folks may need to consider, in order to stay safe. I consider symbolic interposition to be one of those things. Linux users might not feel comfortable about the fact that glibc currently makes it so easy to intercept system calls to Linux Kernel's RNG, that your upstream dependencies might actually compromise your key generator unintentionally. Don't you think that's worth discussing? We could also talk about the concerns surrounding Layered Service Providers, which is another great example of userspace libraries misrepresenting APIs that are generally believed to be talking to the operating system.
        quotemstr 7y ago
        It's not "how [you] talk". It's that you're not making an actual point. There is no "safety" threat here, nor is there an "infrastructural weakness[]". Fretting about "safety" without identifying a threat model is vacuous. What is, specifically, your threat model? What security guarantees can a program make only through bypassing libc? Why aren't the vast majority of programs --- the ones that call libc --- vulnerable to this ineffable threat? Users get to control how programs execute. They can interpose symbols. They can disassemble programs. They can run programs under a debugger. They can modify the kernel. They can run programs in a VM. A program can't detect this intermediation; nor does it have any right to do so. A program has no business breaking random OS visibility and control features. We generally call the ones that try malware. Bypassing libc when making system calls doesn't give a program any insurance against environmental changes. It just inconveniences users while providing no "safety" guarantees. If you want full control over a program's execution environment, ship an appliance.

by cesarb 7y ago

jart 7y ago

Imagine the modern PC as being just another substrate of this great battlefield where big corporations duke it out with each other and the individual owners are becoming less and less relevant to the security story. It's unpleasant. It seems to get raunchier each year. I've even seen household names retool things like graphics drivers to inject data harvesting code into command-line programs at runtime. Then the big companies who don't play dirty like that, usually react by demanding greater authoritarianism in tools, until the rest of us devs find ourselves smothered with -fpic aslr retpoline code-signed bubblewrapping, which isn't so much keeping us safe, but rather keeping big company A safe from big company B. Everything that the guy you linked said is correct. But locks aren't that relevant anymore, once the wolves have been invited in to live.

quotemstr 7y ago
You've used a lot of rhetoric, but you haven't described a threat model. Both this comment and your previous one, the GP, use language of moral duty when talking about a specific software security measure. That's a category error. What specific threat is bypassing libc supposed to protect against? I don't think you have an argument here. As the poster to whom you're replying mentioned, anyone who can do symbol interposition already has full control over your program.
- jart 7y ago
  Perhaps you could share specific details on the use cases that dynamic symbol interposition is intended to serve? Because the only one I think I've seen so far is setbuf(1) and I can imagine more than a few alternatives that could have been considered.
  - quotemstr 7y ago
    Enumerating specific interposition user cases has nothing to do with the point I made, which is about threat modeling. You still have not articulated any specific threat model; you've instead tried to distract the conversation and move it in a different direction.
    - jart 7y ago
      You're welcome to complain about how I talk, but this isn't about me. This is about serving the user and making sure tech behaves the way they expect it to. We need to raise awareness of infrastructural weaknesses that folks may need to consider, in order to stay safe. I consider symbolic interposition to be one of those things. Linux users might not feel comfortable about the fact that glibc currently makes it so easy to intercept system calls to Linux Kernel's RNG, that your upstream dependencies might actually compromise your key generator unintentionally. Don't you think that's worth discussing? We could also talk about the concerns surrounding Layered Service Providers, which is another great example of userspace libraries misrepresenting APIs that are generally believed to be talking to the operating system.
      - quotemstr 7y ago
        It's not "how [you] talk". It's that you're not making an actual point. There is no "safety" threat here, nor is there an "infrastructural weakness[]". Fretting about "safety" without identifying a threat model is vacuous. What is, specifically, your threat model? What security guarantees can a program make only through bypassing libc? Why aren't the vast majority of programs --- the ones that call libc --- vulnerable to this ineffable threat? Users get to control how programs execute. They can interpose symbols. They can disassemble programs. They can run programs under a debugger. They can modify the kernel. They can run programs in a VM. A program can't detect this intermediation; nor does it have any right to do so. A program has no business breaking random OS visibility and control features. We generally call the ones that try malware. Bypassing libc when making system calls doesn't give a program any insurance against environmental changes. It just inconveniences users while providing no "safety" guarantees. If you want full control over a program's execution environment, ship an appliance.