8 ms·

Proper and easy to use support for sandboxes at the OS level, or better yet capabilities, seems like the only long term solution. Many things I run I want to l

by jonahx 27d ago

Proper and easy to use support for sandboxes at the OS level, or better yet capabilities, seems like the only long term solution. Many things I run I want to limit to r/w a single dir, and to have to request permission to make network calls.

hnlmorg 27d ago
Two problems with this: 1. There isn’t a single universal standard for sandboxing across all the different platforms that are supported by Rust. 2. Even if there were, if you’re compiling untrusted code then why would you trust the built output? If you’re building the create then I’d argue that any preventative steps afterwards is akin to closing the barn door after the horse has already bolted.
- fidotron 27d ago
  > 1. There isn’t a single universal standard for sandboxing across all the different platforms that are supported by Rust. Yeah, let's hold up the entire world of offensive cybersecurity capability while you work on that. Sure they will wait. > 2. Even if there were, if you’re compiling untrusted code then why would you trust the built output? You don't. You sandbox the hell out of it too.
  - hnlmorg 27d ago
    > Yeah, let's hold up the entire world of offensive cybersecurity capability while you work on that. Sure they will wait. Nice sarcasm but you’re not actually addressing a solution to the problem I raised. > You don't. You sandbox the hell out of it too. So you’re now saying it’s ok to have exploits compiled into your application as long as it’s sandboxed? I wonder how customers of your application feel about that? I’m certainly not going to be entering my bank details into your ecommerce platform (to give just one obvious example why your suggestion wouldn’t work).
    - nathan_compton 26d ago
      This response seems disingenuous. It was never implied it was ok to have exploits in the compiled software, only that the blast radius is smaller if the compiled code is also sandboxed.
      - hnlmorg 26d ago
        Smaller maybe. But it’s still an unacceptable risk. I refer you back to my example of compiled code being used by customers. Arguing that compromised code is safer when sandboxed really misses the real problem: that you’re running compromised code in the first place. Hence my analogy of closing the barn door after the horse has already bolted. What we need is to ensure we have stronger safeguards in place to prevent bad code from reaching build pipelines. If it’s in the build pipelines then we’ve already lost. I get why people argue about sandboxing, it’s an easier problem to solve. But you still end up with a compromised artefact which you cannot ship. So the benefit is negligible.
    - fidotron 26d ago
      > Nice sarcasm but you’re not actually addressing a solution to the problem I raised. Are you not concerned about an asteroid impact rendering you extinct during your next Rust build? Why not? That's the same level of relevance as your supposed concern. > So you’re now saying it’s ok to have exploits compiled into your application as long as it’s sandboxed? You need to act like it is compromised in all cases, just like everything else. > I wonder how customers of your application feel about that? I’m certainly not going to be entering my bank details into your ecommerce platform (to give just one obvious example why your suggestion wouldn’t work). So your version is "we trust everyone and don't verify anything". Yeah, that's going to work. By your "logic" firewalls wouldn't be necessary.
      - hnlmorg 26d ago
        > Are you not concerned about an asteroid impact rendering you extinct during your next Rust build? Why not? That's the same level of relevance as your supposed concern. That’s a strawman argument and you’re still dodging the question. > You need to act like it is compromised in all cases, just like everything else. No. I act like compromised code is a legitimate risk regardless of how well your build pipeline is sandboxed. I don’t understand why this is a hard concept for you to grasp. > So your version is "we trust everyone and don't verify anything". Yeah, that's going to work. By your "logic" firewalls wouldn't be necessary. That’s the literal opposite of my point (as well as another strawman).
- jonahx 27d ago
  > There isn’t a single universal standard for sandboxing across all the different platforms that are supported by Rust. I said OS level. It's something I should easily be able to do via the OS capabilities that would work for rust, npm, etc. I would use it not only for rust builds but for nearly every app on my computer.
  - hnlmorg 27d ago
    That’s already easy to do. In fact most CI/CD pipelines already work this way. The problem is you still have a compromised executable at the end of the pipeline. So you haven’t actually solved much.

by jonahx 27d ago

hnlmorg 27d ago

Two problems with this: 1. There isn’t a single universal standard for sandboxing across all the different platforms that are supported by Rust. 2. Even if there were, if you’re compiling untrusted code then why would you trust the built output? If you’re building the create then I’d argue that any preventative steps afterwards is akin to closing the barn door after the horse has already bolted.

fidotron 27d ago
> 1. There isn’t a single universal standard for sandboxing across all the different platforms that are supported by Rust. Yeah, let's hold up the entire world of offensive cybersecurity capability while you work on that. Sure they will wait. > 2. Even if there were, if you’re compiling untrusted code then why would you trust the built output? You don't. You sandbox the hell out of it too.
- hnlmorg 27d ago
  > Yeah, let's hold up the entire world of offensive cybersecurity capability while you work on that. Sure they will wait. Nice sarcasm but you’re not actually addressing a solution to the problem I raised. > You don't. You sandbox the hell out of it too. So you’re now saying it’s ok to have exploits compiled into your application as long as it’s sandboxed? I wonder how customers of your application feel about that? I’m certainly not going to be entering my bank details into your ecommerce platform (to give just one obvious example why your suggestion wouldn’t work).
  - nathan_compton 26d ago
    This response seems disingenuous. It was never implied it was ok to have exploits in the compiled software, only that the blast radius is smaller if the compiled code is also sandboxed.
    - hnlmorg 26d ago
      Smaller maybe. But it’s still an unacceptable risk. I refer you back to my example of compiled code being used by customers. Arguing that compromised code is safer when sandboxed really misses the real problem: that you’re running compromised code in the first place. Hence my analogy of closing the barn door after the horse has already bolted. What we need is to ensure we have stronger safeguards in place to prevent bad code from reaching build pipelines. If it’s in the build pipelines then we’ve already lost. I get why people argue about sandboxing, it’s an easier problem to solve. But you still end up with a compromised artefact which you cannot ship. So the benefit is negligible.
  - fidotron 26d ago
    > Nice sarcasm but you’re not actually addressing a solution to the problem I raised. Are you not concerned about an asteroid impact rendering you extinct during your next Rust build? Why not? That's the same level of relevance as your supposed concern. > So you’re now saying it’s ok to have exploits compiled into your application as long as it’s sandboxed? You need to act like it is compromised in all cases, just like everything else. > I wonder how customers of your application feel about that? I’m certainly not going to be entering my bank details into your ecommerce platform (to give just one obvious example why your suggestion wouldn’t work). So your version is "we trust everyone and don't verify anything". Yeah, that's going to work. By your "logic" firewalls wouldn't be necessary.
    - hnlmorg 26d ago
      > Are you not concerned about an asteroid impact rendering you extinct during your next Rust build? Why not? That's the same level of relevance as your supposed concern. That’s a strawman argument and you’re still dodging the question. > You need to act like it is compromised in all cases, just like everything else. No. I act like compromised code is a legitimate risk regardless of how well your build pipeline is sandboxed. I don’t understand why this is a hard concept for you to grasp. > So your version is "we trust everyone and don't verify anything". Yeah, that's going to work. By your "logic" firewalls wouldn't be necessary. That’s the literal opposite of my point (as well as another strawman).
jonahx 27d ago
> There isn’t a single universal standard for sandboxing across all the different platforms that are supported by Rust. I said OS level. It's something I should easily be able to do via the OS capabilities that would work for rust, npm, etc. I would use it not only for rust builds but for nearly every app on my computer.
- hnlmorg 27d ago
  That’s already easy to do. In fact most CI/CD pipelines already work this way. The problem is you still have a compromised executable at the end of the pipeline. So you haven’t actually solved much.