4 ms·

I hope no one tries to use the rust "safety" guarantees for security guards. They are designed to prevent bugs not intentional abuse. If perfect without bugs

I hope no one tries to use the rust "safety" guarantees for security guards. They are designed to prevent bugs not intentional abuse. If perfect without bugs they theoretically might be usable for security guards, but it's not where priorities lies when it comes to bug fixes and design. And people mistaking rust safety + no unsafe lint for "security against evil code" could be long term quite an issue for rust in various subtle ways (not technical problems put people problems).

insanitybit 3y ago
They didn't mistake rust safety for anything. This is called out by them as a shrotcoming of their approach that has to be mitigated separately.
- dathinab 3y ago
  Because my comment was "in general" not specific to any specific case I very intentionally did not refer to the paper at all.
  - insanitybit 3y ago
    I guess I find it weird that you posted something totally random and unrelated to the paper as a direct reply to the paper.
zyedidia 3y ago
I agree -- relying on Safe Rust's "guarantees" for security purposes is very likely to be problematic. To make the reasons concrete: for the last 4 years rustc has had a bug that allows writing transmute (arbitrary type conversion) without the use of unsafe: https://zyedidia.github.io/blog/posts/5-safe-transmute/ https://zyedidia.github.io/blog/posts/5-safe-transmute/. This is one of the 77 current open unsoundness bugs on the Rust issue tracker. To make this tenable you would probably have to use a separate language -- maybe some formally-verified minimal Rust-like language, and with different priorities from a people perspective.
- iudqnolq 3y ago
  I am a bit skeptical this is a workable approach long term, but there is a project based on an attempt to enumerate all of Rust's soundness holes and use Rust's compiler infrastructure to detect and forbid them. They think that by erring on the side of forbidding valid code this is feasible. https://news.ycombinator.com/item?id=35501065 https://news.ycombinator.com/item?id=35501065
  - deredede 3y ago
    From the horse's mouth (article of the linked HN post): > PL/Rust contains a small set of lints to block what the developers have deemed the most egregious "I-Unsound" Rust bugs. > [...] > 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 (PostgreSQL itself is not a particularly hardened codebase, after all). They have extra lints to help you avoid what they deem the most common soundness bugs. They make no claims that there is a way to make this approach safe against an attacker.
IshKebab 3y ago
Postgres does that for its new Rust support. https://news.ycombinator.com/item?id=35501065 https://news.ycombinator.com/item?id=35501065 They do ban unsafe and also the stdlib which probably covers a lot of soundness holes. Also I suspect the trust level required is somewhere in the middle.
- dathinab 3y ago
  in most situations custom SQL function are from a trusted source, through potentially run with untrusted inputs in a unprivileged/trusted execution environment. this would mean they don't necessary rely on it for sandboxing untrusted code purpose it's more like a convenient way to write a native extension function through it's still a bit worrisome

insanitybit 3y ago

They didn't mistake rust safety for anything. This is called out by them as a shrotcoming of their approach that has to be mitigated separately.

dathinab 3y ago
Because my comment was "in general" not specific to any specific case I very intentionally did not refer to the paper at all.
- insanitybit 3y ago
  I guess I find it weird that you posted something totally random and unrelated to the paper as a direct reply to the paper.

zyedidia 3y ago

I agree -- relying on Safe Rust's "guarantees" for security purposes is very likely to be problematic. To make the reasons concrete: for the last 4 years rustc has had a bug that allows writing transmute (arbitrary type conversion) without the use of unsafe: https://zyedidia.github.io/blog/posts/5-safe-transmute/ https://zyedidia.github.io/blog/posts/5-safe-transmute/. This is one of the 77 current open unsoundness bugs on the Rust issue tracker. To make this tenable you would probably have to use a separate language -- maybe some formally-verified minimal Rust-like language, and with different priorities from a people perspective.

iudqnolq 3y ago
I am a bit skeptical this is a workable approach long term, but there is a project based on an attempt to enumerate all of Rust's soundness holes and use Rust's compiler infrastructure to detect and forbid them. They think that by erring on the side of forbidding valid code this is feasible. https://news.ycombinator.com/item?id=35501065 https://news.ycombinator.com/item?id=35501065
- deredede 3y ago
  From the horse's mouth (article of the linked HN post): > PL/Rust contains a small set of lints to block what the developers have deemed the most egregious "I-Unsound" Rust bugs. > [...] > 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 (PostgreSQL itself is not a particularly hardened codebase, after all). They have extra lints to help you avoid what they deem the most common soundness bugs. They make no claims that there is a way to make this approach safe against an attacker.

IshKebab 3y ago

Postgres does that for its new Rust support. https://news.ycombinator.com/item?id=35501065 https://news.ycombinator.com/item?id=35501065 They do ban unsafe and also the stdlib which probably covers a lot of soundness holes. Also I suspect the trust level required is somewhere in the middle.

dathinab 3y ago
in most situations custom SQL function are from a trusted source, through potentially run with untrusted inputs in a unprivileged/trusted execution environment. this would mean they don't necessary rely on it for sandboxing untrusted code purpose it's more like a convenient way to write a native extension function through it's still a bit worrisome