A soundness bug in std::fs

[notriddle]

This program writes to arbitrary memory, violating Rust's safety guarantees, despite using no unsafe code:

use std::fs;
use std::io;
use std::io::prelude::*;

fn main() {
    let i = 0;
    let j = &i as *const i32 as u64;
    let mut f = fs::OpenOptions::new().write(true).open("/proc/self/mem").unwrap();
    f.seek(io::SeekFrom::Start(j+16)).unwrap();
    let k = [16; 16];
    f.write(&k).unwrap();
}

Because the filesystem APIs cannot be made safe (blocking /proc paths specifically will not work, because symlinks can be created to it), File::create, File::open, and OpenOptions::open should be marked unsafe. I am working on an RFC for that right now.

[jonas-schievink]

These methods are stable, they cannot be marked unsafe (almost the entire ecosystem would break). I guess things like /proc/self/mem are out of Rust's safety scope.

[notriddle]

According to the stability document:

We reserve the right to fix compiler bugs, patch safety holes, and change type inference in ways that may occasionally require new type annotations.

[jonas-schievink]

may occasionally require new type annotations

unsafe is neither a type annotation nor would it happen "occasionally" since these are so fundamental APIs (okay this just refers to inference changes)

[notriddle]

It's the safety holes part that justifies this. This is a safety hole. It's essentially the same as the scoped thread API, only the scoped thread API was removed from Rust before it was stabilized.

[jonas-schievink]

I wouldn't consider this a safety hole. The fact that harmless file system operations can change arbitrary memory is unfortunate, but there will always be ways to somehow circumvent Rust's safety guarantees with external "help".

The scoped thread API was a process-internal API not provided by the OS but by the Rust standard lib alone, and was only unsafe because of wrong assumptions made while it was designed.

[hanna-kruppe]

Marking a stable function as unsafe would probably be covered by the quoted wording even if the function was widely used, but that doesn't mean it's a reasonable interpretation in this case. Making opening a file unsafe is so baldly ridiculous that I am asking myself if this an April's fools joke.

Surely it is possible got around the symlink thing and avoid opening /proc/self/mem for writing?

[notriddle]

The pre-RFC has now been posted to internals

[jonas-schievink]

It proposes to make println! unsafe. Am now reminded of why I don't like April's fools.

[petrochenkov]

You can also use safe std::process::Command to launch an evil program which invades your process' memory and corrupts it.

[llogiq]

What's worse, you could call unsafe code from safe code! This can only lead to security holes! Let's require unsafe { ..} around all the code and define every function as unsafe to remind programmers that it's a scary world out there...

[jonas-schievink]

The obvious solution is of course not to mark the methods as unsafe, but to drop Linux and Windows support and only support Redox (it's written in Rust so it must be safe) ;)

[hanna-kruppe]

The obvious solution is of course not to mark the methods as unsafe, but to drop Linux and Windows support and only support Redox (it's written in Rust so it must be safe) ;)

That won't do. Redox uses unsafe. To make sure such mistakes don't happen again, we must stop using unsafe, perhaps even remove it after an appropriate waiting period (say, two releases). This will require a rewrite of the unsafe parts of the standard library, but I'm sure the compiler team will be receptive to migrating all the functions that currently use unsafe to compiler intrinsics (which will be safe because the compiler is never wrong).

FWIW I've long harbored thoughts that "safe" Rust does not go far enough. Removing unsafe is only the first step, supposedly "safe" code can still take incredibly dangerous actions (e.g., std::process::Command can be used to invoke rm -rf /). The Rust designers were wise to identify shared mutable access as a huge source of problems, but side effects are still permitted despite the overwhelming evidence that most unsafe code has side effects. Consequently, I'm currently drafting an RFC to make Rust a pure, 100% side-effect free language. main will become a pure action of type impl Unsafe<()>.

... aw crud. That requires a Monad trait. Yet another RFC blocked on HKT!

[notriddle]

Except that deleting everything is not unsafe, while poking around arbitrarily in memory is.

[hanna-kruppe]

That is unfortunate short-sighted corner-cutting. rm -rf / is the number one threat to cyber security. Ignoring it or declaring it out of scope will just diminish Rust's importance.