Security fence for crates

[DrizztVD]

If we are happy verifying only crates without unsafe { .. } blocks, then this can be done purely in the compiler I think, without any run-time cost.

Yep. Although unsafe code can still be caught doing naughty things if you analyze the fuzzing results for syscalls. The OS stack, Windows API and syscalls are not my domain.

The idea is to add a cuckoo sandbox around the fuzzing implementation here to pump all kinds of code into the crate and see if it tries to use the wrong permissions. I think this can work.

[bascule]

Software object capabilities / tags don’t work when you’re allowed to execute arbitrary code (which you can with unsafe ).

If Rust were an OCap language, unsafe would absolutely have be a capability.

This is indeed one of the big challenges with trying to convert Rust into an OCap language: there is presently no way to ensure in a transitive manner that crates are not using unsafe (except for, say, a whitelist selected by the parent application/crate)

[DrizztVD]

transitive manner that crates are not using unsafe

Will #![forbid(unsafe_code)] on crates not work? I’m willing to bet that a security workgroup can cleanse many common Crates of unsafe commands. Hence the Whitelist will turn into a blacklist and OCap can still be done? Also, I need to investigate OCap. In your opinion @bascule, is OCap worth it? And notice the embedded question I had above.?

[bascule]

Will #![forbid(unsafe_code)] on crates not work?

To my knowledge #![forbid(unsafe_code)] only applies within the context of an individual crate, and does not disallow that crate from using other crates which themselves use unsafe or transitively depend on crates that use unsafe.

In your opinion @bascule, is OCap worth it?

I think retrofitting OCap into Rust would be ambitious to say the least. Scoping use of unsafe would be a necessary first step. From there uses of unsafe would need to be tied to capabilities.

[DrizztVD]

Scoping use of unsafe would be a necessary first step. From there uses of unsafe would need to be tied to capabilities.

I was just thinking today of where on earth I’d need to start a literature review on this. Finding relevant academic papers on a subject can be hard because they all end up using jargon that will not show up on a mere google search. Now I can hit WorldCAT with that and spidey-web the literature to see what researchers say with regard to the whole Crates security thing.

It appears to me that NLL was formulated/adapted from literature and conference papers and slowly morphed into what they now call polonius. Perhaps OCap can be adapted and weakened (yes) to make implementation possible without trying to build a Titanic. To be clear, the ship may still well sink, but at least it won’t be much of a loss if it does, and it could still work, in which case we can build it bigger.

To be clear, full OCap implemented on Rust sounds like Titanic to me… It’s complex enough that it will become a silver bullet project that steals manpower from other viable alternatives. With enough manpower that could change. Just imo.

[Tom-Phinney]

Will #![forbid(unsafe_code)] on crates not work? I’m willing to bet that a security workgroup can cleanse many common Crates of unsafe commands.

A first test case might be the classify function in the FloatCore trait in the num crate. Note that it’s actually in the num_traits dependent crate. I suspect that there is no efficient way to eliminate this use of unsafe. Surely few will advocate that the num crate, which is maintained by the Rust core team, should be off limits for use.

[DrizztVD]

I suspect that there is no efficient way to eliminate this use of unsafe .

I wonder if I’m going to kick a hornet’s nest here. But I thought about a way of having parallel code generation possibilities. Meaning that, say a macro is used to read a flag that says: ForbidSecure = True. If true, the macro branches to use a safe routine. if ForbidSecure = False, the macro will take the “efficient” unsafe branch. This aims to remove the branch code from the runtime - the branch instruction does not end up in the binary.

The Medium post says that efficient safe implementation techniques are undocumented. So it’s plausible that at first, the Safe code will be slow, but with time, this can be made faster as the optimisation techniques become better standardized (and stable between LLVM editions I hope).

This means the programmer is given a choicebetween safe code and slightly faster code. Right now, the programmer does not have a choice and unsafe if forced upon him or her unceremoniously (so disgraceful )

[felix91gr]

This is very interesting. It must be well-backed by some sort of testing suite that checks identical results, just to be sure that both branches implement the same functionality.

This, because since we’d be implementing the same feature twice, we would effectively have a sort of code duplication which we’d have to mitigate the impacts of

[bascule]

Surely few will advocate that the num crate, which is maintained by the Rust core team, should be off limits for use.

I think restricting usage of unsafe needs a crate-by-crate whitelisting feature. I don’t think we want to tell people they can’t use libc. You can imagine a feature like that requiring the consumers of crates to whitelist the same crates their dependencies whitelist (perhaps with a combination of a global whitelist or crate-by-crate whitelists) or getting a compile error.

[anderejd]

Surely few will advocate that the num crate, which is maintained by the Rust core team, should be off limits for use.

I think restricting usage of unsafe needs a crate-by-crate whitelisting feature. I don’t think we want to tell people they can’t use libc. You can imagine a feature like that requiring the consumers of crates to whitelist the same crates their dependencies whitelist (perhaps with a combination of a global whitelist or crate-by-crate whitelists) or getting a compile error.

A whitelist like this is on the roadmap for https://crates.io/crates/cargo-geiger

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.