5 ms·

This could be interesting but the biggest problem is that “unsafe” is a master permission that implies all other permissions in addition to memory and thread sa

This could be interesting but the biggest problem is that “unsafe” is a master permission that implies all other permissions in addition to memory and thread safety weaknesses. With unsafe you can do file I/O, process, net etc. for example, the nix crate can do all of this without ever touching the std APIs. Now of course you could disallow unsafe in most crates, but any that do are now much higher value for compromise. > That said, using unsafe to say perform network access is harder than just using Rust’s std::net APIs, so we’re at least making it harder for a would-be attacker No, it’s actually quite easy. Done every day by C and C++ developers and in a few hours you have built up some high level APIs. Heck you can copy paste the std or nix implementations since that’s what they’re doing under the hood anyway.

ghusbands 3y ago
It's still an improvement, and having a significant number of your imports be unable to use any kind of unsafe code or access files or the network greatly decreases the amount of code review you need. If I import a jpeg decoder that works only on buffers I provide and has no unsafe code or equivalents, then I don't have to worry about it exfiltrating any personal data.
btown 3y ago
A semi-automated system that compares old unsafe code to new unsafe code would likely be really helpful here - say, a LLM prompted to investigate whether the new unsafe blocks are a significant difference in scope and documented intent from the old unsafe blocks. Unless the winners of https://www.ioccc.org/ https://www.ioccc.org/ are among your attackers, it's a pretty solid line of defense.
njs12345 3y ago
I could see a combination of this approach and one of the audit approaches like `cargo crev` working well in the unsafe case: - Require audit if there is new unsafe code - Otherwise, rely on cackle to enforce no use of fs/net etc in safe Rust This could provide the best of both worlds, automating most of the audit burden while still providing strong guarantees.
tedunangst 3y ago
You wouldn't want the unsafe in your own crate, of course. You'd leave that for the javascript jit, which nobody will think twice about. You definitely need JavaScript because you want to talk to polkit, because of course the user should be allowed to select a color profile. Naturally. And then, oops, maybe a little extra JavaScript gets passed to the interpreter that does some funny stuff.
etna_ramequin 3y ago
You don’t even need unsafe to reproduce unsafe behaviour on Linux. You can just read and write to `/proc/self` and modify memory arbitrarily. If you have `std::fs`, then you have `unsafe`, then you’ve got everything. In general, sandboxes don’t work well at the language level. You really need to go at the system level.
- whaleofatw2022 3y ago
  Yup. Even at the language VM level, it doesn't seem to be tenable. Microsoft tried to go all out on this back in the day with Code Access Security. I remember three things about it: 1. Engineers/sysadmins would easily get frustrated, and just let the app run under full trust 2. Perf issues, since security demands would result in checking the call stack up 3. When they changed things in .NET 4 a lot of web code would break unless you added a magical attribute. Needless to say, microsoft more or less gave up on it in .NET core
  - etna_ramequin 3y ago
    WDYT of WASM capability system? IMO, it would be a good contender for sandboxing dependencies. However, I haven’t tested it in practice.
    - whaleofatw2022 3y ago
      Does it have a threading model yet? Otherwise I'm not good enough to even try.
  - marwis 3y ago
    Same thing with Java Security Manager which is in the process of being removed with no replacement. Unfortunately supply chain security is incompatible with developer convenience. At least not without a lot of work to make it bearable. We will have to suffer through a lot worse attacks than now before people will take it serious (most developers likely never but governments will at some point intervene - see EU's CSA).
Aeolun 3y ago
> in a few hours you have built up some high level APIs I think this is what OP is talking about when he calls using the std::net API’s easier. Driveby hackers are (probably) not going to spend a few hours re-implementing a network call.

ghusbands 3y ago

It's still an improvement, and having a significant number of your imports be unable to use any kind of unsafe code or access files or the network greatly decreases the amount of code review you need. If I import a jpeg decoder that works only on buffers I provide and has no unsafe code or equivalents, then I don't have to worry about it exfiltrating any personal data.

btown 3y ago

A semi-automated system that compares old unsafe code to new unsafe code would likely be really helpful here - say, a LLM prompted to investigate whether the new unsafe blocks are a significant difference in scope and documented intent from the old unsafe blocks. Unless the winners of https://www.ioccc.org/ https://www.ioccc.org/ are among your attackers, it's a pretty solid line of defense.

njs12345 3y ago

I could see a combination of this approach and one of the audit approaches like `cargo crev` working well in the unsafe case: - Require audit if there is new unsafe code - Otherwise, rely on cackle to enforce no use of fs/net etc in safe Rust This could provide the best of both worlds, automating most of the audit burden while still providing strong guarantees.

tedunangst 3y ago

You wouldn't want the unsafe in your own crate, of course. You'd leave that for the javascript jit, which nobody will think twice about. You definitely need JavaScript because you want to talk to polkit, because of course the user should be allowed to select a color profile. Naturally. And then, oops, maybe a little extra JavaScript gets passed to the interpreter that does some funny stuff.

etna_ramequin 3y ago

You don’t even need unsafe to reproduce unsafe behaviour on Linux. You can just read and write to `/proc/self` and modify memory arbitrarily. If you have `std::fs`, then you have `unsafe`, then you’ve got everything. In general, sandboxes don’t work well at the language level. You really need to go at the system level.

whaleofatw2022 3y ago
Yup. Even at the language VM level, it doesn't seem to be tenable. Microsoft tried to go all out on this back in the day with Code Access Security. I remember three things about it: 1. Engineers/sysadmins would easily get frustrated, and just let the app run under full trust 2. Perf issues, since security demands would result in checking the call stack up 3. When they changed things in .NET 4 a lot of web code would break unless you added a magical attribute. Needless to say, microsoft more or less gave up on it in .NET core
- etna_ramequin 3y ago
  WDYT of WASM capability system? IMO, it would be a good contender for sandboxing dependencies. However, I haven’t tested it in practice.
  - whaleofatw2022 3y ago
    Does it have a threading model yet? Otherwise I'm not good enough to even try.
- marwis 3y ago
  Same thing with Java Security Manager which is in the process of being removed with no replacement. Unfortunately supply chain security is incompatible with developer convenience. At least not without a lot of work to make it bearable. We will have to suffer through a lot worse attacks than now before people will take it serious (most developers likely never but governments will at some point intervene - see EU's CSA).

Aeolun 3y ago

> in a few hours you have built up some high level APIs I think this is what OP is talking about when he calls using the std::net API’s easier. Driveby hackers are (probably) not going to spend a few hours re-implementing a network call.