Running *.wasm files directly doesn't sandbox the filesystem

[yagehu]

In wasmtime or other Wasm runtimes with WASI support, you have to explicit preopen a directory to have access to the host filesystem. With wasmer, it seems the cwd is opened by default.

For example, given this small Rust program:

fn main() {
    let f = std::fs::OpenOptions::new()
        .write(true)
        .create_new(true)
        .open("abc")
        .unwrap();
}

Running it as wasmer run test.wasm will just create a file named abc in cwd. Is it possible to disable this behavior. I only want host fs access if I explicitly enable it.

The above program is compiled with cargo build --target wasm32-wasi.

[Arshia001]

Hey @yagehu!

Are you sure you're not mounting the directory via --mapdir /:.? AFAIK, no directories are mounted automatically when running wasmer without --mapdir or --dir.

[Arshia001]

@yagehu never mind, I just ran it and it does indeed mount the cwd.

[Michael-F-Bryan]

I have a feeling the issue comes from the way we set up the preopens here:

wasmer/lib/cli/src/commands/run/wasi.rs

Lines 193 to 226 in 9127dde

	let mut builder = if wasmer_wasix::is_wasix_module(module) {
	// If we preopen anything from the host then shallow copy it over
	let root_fs = RootFileSystemBuilder::new()
	.with_tty(Box::new(DeviceFile::new(__WASI_STDIN_FILENO)))
	.build();
	if !self.mapped_dirs.is_empty() {
	let fs_backing: Arc<dyn FileSystem + Send + Sync> =
	Arc::new(PassthruFileSystem::new(default_fs_backing()));
	for MappedDirectory { host, guest } in self.mapped_dirs.clone() {
	let host = if !host.is_absolute() {
	Path::new("/").join(host)
	} else {
	host
	};
	root_fs.mount(guest.into(), &fs_backing, host)?;
	}
	}
	// Open the root of the new filesystem
	builder
	.sandbox_fs(root_fs)
	.preopen_dir(Path::new("/"))
	.unwrap()
	.map_dir(".", "/")?
	} else {
	builder
	.fs(default_fs_backing())
	.preopen_dirs(self.pre_opened_directories.clone())?
	.map_dirs(
	self.mapped_dirs
	.iter()
	.map(|d| (d.guest.clone(), d.host.clone())),
	)?
	};

[theduke]

This was resolved in #4301 .

[yagehu]

@theduke Will you publish the security advisory?

[theduke]

@yagehu which version of wasmer are you on, and which operating system?

Because this does not reproduce on wasmer 4.2.3 on Linux.

[Arshia001]

@theduke you have to compile to wasm32-wasi, the issue does not exist in wasm32-wasmer-wasi.

[Arshia001]

never mind, it just doesn't happen with cargo wasix run, probably because cargo-wasix changes wasmer's pwd to something else.

[yagehu]

@yagehu which version of wasmer are you on, and which operating system?

Because this does not reproduce on wasmer 4.2.3 on Linux.

This reproduces with v4.2.3 Wasmer on Fedora 39 Linux. It does NOT reproduce with v4.2.4 Wasmer, so I'm assuming your commit fixed it. I'm just wondering if you will publish the security advisory since it impacts people running plain WASI (non WASIX) workloads.

[Arshia001]

@yagehu we ran into a bit of a hiccup with publishing the crates. That's been resolved and the advisory will be published soon. Tagging @syrusakbary

[Arshia001]

@yagehu the advisory is now published. I will close this issue.