6 ms·

only when using `unsafe` which this forbids

tyingq 4y ago
I don't know much about rust, so it seemed odd to me that just forbidding unsafe would make for a reasonable sandbox. At least for the postgres concept of "trusted language", that's supposed to mean things like closing off access to the filesystem. Not just typical file io calls either, but more obscure stuff like sendfile(). I do see that rust access to sendfile() would be via a syscall, which is in the unsafe category...so perhaps that's not the best example. But it does make me curious how comprehensive a sandbox PL/Rust is providing, beyond just forbidding unsafe.
- iudqnolq 4y ago
  pl/rust is its own target platform, so they provide their own standard library*. The IO stuff all panics, for example. (In Rust a panic should be used to indicate invariant failure. pl/rust catches panics and converts them to postgres errors). In Rust you'd normally be able to link c code, but calling c requires unsafe because you have to manually ensure the c code upholds any relevant Rust invariants. > But it does make me curious how comprehensive a sandbox PL/Rust is providing, beyond just forbidding unsafe. They also hook the compiler and try and detect shenanigans. It's not perfect, but it's pretty thought out. *Technically the Rust standard library builds on top of a lower-level io module, which is all you have to replace.
- gpm 4y ago
  More than just forbidding unsafe, but not enough to make this secure against competent adversaries by their own admission. They argue postgres itself isn't secure against competent adversaries so this doesn't matter too much. https://tcdi.github.io/plrust/plrust.html#what-about-rust-compiler-bugs https://tcdi.github.io/plrust/plrust.html#what-about-rust-co... Rust keeps a list of soundness bugs via a tag on github - they're pretty common: 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...
- yarg 4y ago
  Read the article, they specify that they use a compiler target that restricts system access. As I read it, it seemed that the unsafe prohibition was more about the safety of the code and not the security of the system.
formalLogicGirl 4y ago
And there is also an alternative implementation to Rust std that blocks, among others, filesystem access via std::fs https://github.com/tcdi/postgrestd https://github.com/tcdi/postgrestd
chrismorgan 4y ago
This implementation blocks file system access and is thus not vulnerable, but note that in Rust in general you can actually violate safety on some platforms without any `unsafe` by modifying magic files like /proc/self/mem. This is a known issue but considered unfixable (because the technical solution of marking opening a file as unsafe would cause far more trouble than it could ever hope to solve).
- IshKebab 4y ago
  It's more of an interesting fact than an issue to be fixed.

I don't know much about rust, so it seemed odd to me that just forbidding unsafe would make for a reasonable sandbox. At least for the postgres concept of "trusted language", that's supposed to mean things like closing off access to the filesystem. Not just typical file io calls either, but more obscure stuff like sendfile(). I do see that rust access to sendfile() would be via a syscall, which is in the unsafe category...so perhaps that's not the best example. But it does make me curious how comprehensive a sandbox PL/Rust is providing, beyond just forbidding unsafe.

iudqnolq 4y ago
pl/rust is its own target platform, so they provide their own standard library*. The IO stuff all panics, for example. (In Rust a panic should be used to indicate invariant failure. pl/rust catches panics and converts them to postgres errors). In Rust you'd normally be able to link c code, but calling c requires unsafe because you have to manually ensure the c code upholds any relevant Rust invariants. > But it does make me curious how comprehensive a sandbox PL/Rust is providing, beyond just forbidding unsafe. They also hook the compiler and try and detect shenanigans. It's not perfect, but it's pretty thought out. *Technically the Rust standard library builds on top of a lower-level io module, which is all you have to replace.
gpm 4y ago
More than just forbidding unsafe, but not enough to make this secure against competent adversaries by their own admission. They argue postgres itself isn't secure against competent adversaries so this doesn't matter too much. https://tcdi.github.io/plrust/plrust.html#what-about-rust-compiler-bugs https://tcdi.github.io/plrust/plrust.html#what-about-rust-co... Rust keeps a list of soundness bugs via a tag on github - they're pretty common: 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...
yarg 4y ago
Read the article, they specify that they use a compiler target that restricts system access. As I read it, it seemed that the unsafe prohibition was more about the safety of the code and not the security of the system.

formalLogicGirl 4y ago

And there is also an alternative implementation to Rust std that blocks, among others, filesystem access via std::fs https://github.com/tcdi/postgrestd https://github.com/tcdi/postgrestd

chrismorgan 4y ago

This implementation blocks file system access and is thus not vulnerable, but note that in Rust in general you can actually violate safety on some platforms without any `unsafe` by modifying magic files like /proc/self/mem. This is a known issue but considered unfixable (because the technical solution of marking opening a file as unsafe would cause far more trouble than it could ever hope to solve).

IshKebab 4y ago
It's more of an interesting fact than an issue to be fixed.