Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Secure Rust Guidelines

anssi-fr.github.io

Post reply on HN
Print view View original

11–20 of 29 posts

Re: Secure Rust Guidelines

#11

Post by tialaramex »

mlindner wrote: post #10
liftm wrote: post #6

> In a secure Rust development, the code must not leak memory or resource in particular via Box::leak. Uh, so is Box::leak forbidden in general? Because creating a &'static in some initialization code that lives for the rest of the program is a rather common use case… https://docs.rs/log/0.4.17/src/log/lib.rs.html#1408 Or is it only forbidden if it's actually a leak?

How is it a leak if it still has a reference? I only would classify something as a leak if it has no remaining valid references to some piece of data.

It's usually considered a leak if we can't release it.

Arguably you can release the thing you leaked with Box::leak(). Just tell Box you want a new box that's just a thin wrapper for your mutable reference (this is unsafe), then drop the box. But generally the purpose of Box::leak() is to never release the thing inside the box.

So, yes, you could argue semantically about whether this is "really" a leak but in practice that's why it's named Box::leak()

Re: Secure Rust Guidelines

#12

Post by MrJohz »

noodledoodletwo wrote: post #9
Aissen wrote: post #5

Earlier quoted context omitted.

I fully agree, but then it would be integrated with Clippy or in a wiki with a page per code (like shellcheck). The document in this post is helpful because it does the first step of explaining the rationals, that can then eventually be automated (and then/copy pasted in the explanations).

I agree with you all. Bake it into clippy or make a different clippy aka seclippy. Also, I appreciate the docs so I understand why with examples. Also make a attribute that blocks some of these things

> seclippy

According to a quick search, I propose "trombine" as the French version of clippy.

Re: Secure Rust Guidelines

#13

Post by liftm »

alpaca128 wrote: post #7
liftm wrote: post #6

> In a secure Rust development, the code must not leak memory or resource in particular via Box::leak. Uh, so is Box::leak forbidden in general? Because creating a &'static in some initialization code that lives for the rest of the program is a rather common use case… https://docs.rs/log/0.4.17/src/log/lib.rs.html#1408 Or is it only forbidden if it's actually a leak?

> creating a &'static in some initialization code that lives for the rest of the program is a rather common use case Isn't that the use-case for lazy_static? Or SyncOnceCell once it's in stable Rust. Though I'm not sure how it's implemented under the hood.

Hm, good point. (It's implemented as a Once (which is an atomic usize) and an UnsafeCell for holding the actual data.) And while using SyncOnceCell normally might incur some small checking overhead on each access, you can use it to obtain a &'static. https://play.rust-lang.org/?version=nightly&mode=debug&editi...

But then, by tialaramex's logic, isn't it just as bad as Box::leak? (Maybe not quite as, because it can leak maximally one thing. You can't do this in a loop.)

Re: Secure Rust Guidelines

#14

Post by Grimburger »

Disappointed there's no mention of vendoring. Anyone with _proper_ security concerns should cargo vendor by default.

Last I looked supply chain attackers don't respect semver and you are all one casual offhand cargo update away from catastrophe.

Re: Secure Rust Guidelines

#15

Post by rpigab »

MrJohz wrote: post #12
noodledoodletwo wrote: post #9

Earlier quoted context omitted.

I agree with you all. Bake it into clippy or make a different clippy aka seclippy. Also, I appreciate the docs so I understand why with examples. Also make a attribute that blocks some of these things

> seclippy According to a quick search, I propose "trombine" as the French version of clippy.

Don't you mean trombone? Or is there a hidden pun?

Re: Secure Rust Guidelines

#16

Post by viccuad »

Grimburger wrote: post #14

Disappointed there's no mention of vendoring. Anyone with _proper_ security concerns should cargo vendor by default. Last I looked supply chain attackers don't respect semver and you are all one casual offhand cargo update away from catastrophe.

I don't think vendoring helps at all. People can't review all the dependencies' code. And recursively, for the dependencies of the dependencies. At some point, you delegate trust.

What helps is having provenance information, signing and SBOM. One example. https://sigstore.dev (vendor neutral effort from the Linux Foundation).

Re: Secure Rust Guidelines

#17

Post by tonyzzz »

The link to "rust-bindgen" in page https://anssi-fr.github.io/rust-guide/07_ffi.html seems to be broken. I think it probably refers to "bindgen" (https://crates.io/crates/bindgen).

EDIT: the broken link is introduced when replacing Github link to Crates.io link: https://github.com/ANSSI-FR/rust-guide/commit/49822911e4f14b...

Re: Secure Rust Guidelines

#18

Post by puffoflogic »

Sadly these guidelines are as incoherent as last time. For example, the rules absolutely forbid using an `unsafe` block to call a rust function (since this falls in none of the allowed uses of `unsafe`), but then the rules turn around and require the use of `unsafe` to zero out variables.

Re: Secure Rust Guidelines

#19

Post by estebank »

Grimburger wrote: post #14

Disappointed there's no mention of vendoring. Anyone with _proper_ security concerns should cargo vendor by default. Last I looked supply chain attackers don't respect semver and you are all one casual offhand cargo update away from catastrophe.

For applications (as opposed to libraries), Cargo.lock fulfills the same function as vendoring, but lets cargo audit continue working as expected.

Re: Secure Rust Guidelines

#20

Post by pornel »

mlindner wrote: post #10
liftm wrote: post #6

> In a secure Rust development, the code must not leak memory or resource in particular via Box::leak. Uh, so is Box::leak forbidden in general? Because creating a &'static in some initialization code that lives for the rest of the program is a rather common use case… https://docs.rs/log/0.4.17/src/log/lib.rs.html#1408 Or is it only forbidden if it's actually a leak?

How is it a leak if it still has a reference? I only would classify something as a leak if it has no remaining valid references to some piece of data.

Because when you drop that reference, the memory won't be reclaimed, and destructors won't run.

References in Rust aren't like references in GC languages. They don't control object's lifetime.

Post reply on HN