4 ms·

Normally yes, but it looks like the trusted PL/Rust being discussed here is limited to some subset of Rust. They specifically note that `unsafe` code is not all

Normally yes, but it looks like the trusted PL/Rust being discussed here is limited to some subset of Rust. They specifically note that `unsafe` code is not allowed, which means you can't (for example) implement your own syscalls or construct a pointer into postgres internals memory. However, they make it clear that this is not intended to be your only defence against an attacker: > Note that this is done on a best-effort basis, and does not provide a strong level of security — it's not a sandbox, and as such, it's likely that a skilled hostile attacker who is sufficiently motivated could find ways around it

IshKebab 4y ago
I don't think it's really any defence at all against an attacker. I don't think Rust's `unsafe` was ever intended to be a security boundary. Surely all a "sufficiently motivated" attacker would need to do is peruse the unsound bugs on GitHub? https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AI-unsound https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Ais... Those aren't considered to be security issues. Makes me wonder what the point of banning `unsafe` is at all. You're going to need some other system anyway...
- feike 4y ago
  The trust is not just banning unsafe, it is using a limited std: > The "trusted" version of PL/Rust uses a unique fork of Rust's std entitled postgrestd when compiling LANGUAGE plrust user functions. https://github.com/tcdi/postgrestd https://github.com/tcdi/postgrestd
  - IshKebab 4y ago
    That doesn't matter. If you can use `unsafe` you can make syscalls directly.
    - ekimekim 4y ago
      A large number of unsoundness bugs only work if you have access to the stdlib, because they're flaws in stdlib types and functions that use `unsafe` internally, and are supposed to present a safe interface around it. If you a) don't have access to unsafe, and b) don't have access to the stdlib that lets you do powerful things without unsafe, then you're very limited in what you can do. https://smallcultfollowing.com/babysteps/blog/2016/10/02/observational-equivalence-and-unsafe-code/ https://smallcultfollowing.com/babysteps/blog/2016/10/02/obs... discusses this further. Conceptually, you can think of "entirely Safe Rust" to be a very limited language, which you then progressively add "capabilites" to by exposing safe interfaces implemented with unsafe code. For example, Vec and Box (which require unsafe) grant safe code the ability to do heap allocations. It's true that this is not designed as a security boundary. As I note in my comment above, the PL/Rust devs also make that clear. That doesn't mean it has no value as part of a defence in depth strategy.
- workingjubilee 4y ago
  The rustc driver for trusted PL/Rust prevents using the subset of the Rust language required to trigger those issues. Most of them are things that would have a hard time traversing the Postgres procedure call boundary, anyways, in a legitimate use-case, so this isn't expected to meaningfully affect actual user code.
vlovich123 4y ago
So you have to give them your rust code to compile on your behalf then?

IshKebab 4y ago

I don't think it's really any defence at all against an attacker. I don't think Rust's `unsafe` was ever intended to be a security boundary. Surely all a "sufficiently motivated" attacker would need to do is peruse the unsound bugs on GitHub? https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AI-unsound https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Ais... Those aren't considered to be security issues. Makes me wonder what the point of banning `unsafe` is at all. You're going to need some other system anyway...

feike 4y ago
The trust is not just banning unsafe, it is using a limited std: > The "trusted" version of PL/Rust uses a unique fork of Rust's std entitled postgrestd when compiling LANGUAGE plrust user functions. https://github.com/tcdi/postgrestd https://github.com/tcdi/postgrestd
- IshKebab 4y ago
  That doesn't matter. If you can use `unsafe` you can make syscalls directly.
  - ekimekim 4y ago
    A large number of unsoundness bugs only work if you have access to the stdlib, because they're flaws in stdlib types and functions that use `unsafe` internally, and are supposed to present a safe interface around it. If you a) don't have access to unsafe, and b) don't have access to the stdlib that lets you do powerful things without unsafe, then you're very limited in what you can do. https://smallcultfollowing.com/babysteps/blog/2016/10/02/observational-equivalence-and-unsafe-code/ https://smallcultfollowing.com/babysteps/blog/2016/10/02/obs... discusses this further. Conceptually, you can think of "entirely Safe Rust" to be a very limited language, which you then progressively add "capabilites" to by exposing safe interfaces implemented with unsafe code. For example, Vec and Box (which require unsafe) grant safe code the ability to do heap allocations. It's true that this is not designed as a security boundary. As I note in my comment above, the PL/Rust devs also make that clear. That doesn't mean it has no value as part of a defence in depth strategy.
workingjubilee 4y ago
The rustc driver for trusted PL/Rust prevents using the subset of the Rust language required to trigger those issues. Most of them are things that would have a hard time traversing the Postgres procedure call boundary, anyways, in a legitimate use-case, so this isn't expected to meaningfully affect actual user code.

vlovich123 4y ago

So you have to give them your rust code to compile on your behalf then?