Hacker News Reader

Comment by vlovich123 | Hacker News Reader

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.

View on HN

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.

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

WDYT of WASM capability system? IMO, it would be a good contender for sandboxing dependencies. However, I haven’t tested it in practice.

Does it have a threading model yet? Otherwise I'm not good enough to even try.

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).

IDK what JSM looked like to use, but .NET permissions were in some ways arcane and sneaky.

Back then, you often just ran VS as local admin, supply chain attacks weren't a 'real' thing most of the time, so NBD.

So then you try to deploy your app, and discover the joys of signed assemblies.

And you -make absolutely sure- when you leave, you give instructions to rebuild the whole pipeline if need be.

TBH at least we knew there was the polite illusion of a sandbox...

It's true that every layer of the stack needs every layer below it to take security seriously. But that's not an argument against hardening languages, because they're also a part of the stack that upper layers rely on upon.

I dont disagree with this. I just want to highlight that to do this sort of sandboxing in any systematic manner, you’ll always need to go down at the system level. Because here we’re trying to sandbox the system using abstraction at the language level which is bound to run into impedance mismatch. I don’t think it’s the role of the language to restrict which system calls are acceptable.

However, there is some appeal to the syntax introduced by the author if we use it for a proper and portable sandboxing mechanism. Maybe WASI, with capabilities?

To be more specific, there’s no reason for rust to know that writing to a specific file will allow modifying the program’s memory. It’s also not a security problem from the system, it’s just how it works. It really only makes sense for the system to enforce that kind of sandboxing, because it has enough context to enforce things sensibly.

I'd prefer 'sandboxes' at an even lower, function-level, such as with Austral-lang's capabilities: https://news.ycombinator.com/item?id=34168452

There you can more exactly specify what a function may do, instead of relying on blunt categories like "filesystem".

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.

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.

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.

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/ are among your attackers, it's a pretty solid line of defense.

> 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.

Reply on news.ycombinator.com