Limitations of build-time code execution in cargo

[georgelyon]

Hi,

I was just wondering if there were any limitations on what code I can execute as a build script in cargo? I’d assume some restrictions are there to prevent an attacker from stealing credentials or the like, but I couldn’t find any documentation of this.

As a follow up, has there been any exploration of running either cargo or the created binary in a sandbox?

[Soni]

As a follow up, has there been any exploration of running either cargo or the created binary in a sandbox?

play.rust-lang.org ? I’m not sure if it uses cargo or rustc directly but I think it supports some crates?

[eminence]

There are no limitations about what a build.rs script can do. It can steal credentials, re-format your harddrive, or do all sorts of bad stuff.

A sandbox would be neat. I’m curious if any other languages/ecosystems provide a sandbox for build script (I’m not aware of any, but I’ve not done an extensive survey).

[cuviper]

FWIW, the same trust issue exists with any classic ./configure && make.

[johnthagen]

I’ve always hoped that eventually once Cargo can support everything we need in a declarative sense in Cargo.toml that pure-Rust projects wouldn’t need build scripts any longer and perhaps a user could just disallow any build scripts. But that’s probably too idealistic, especially with the amount of C libraries that are still bound to.

[cuviper]

It’s not just build scripts – proc-macro plugins (custom #[derive]) also get to execute at build time.

[kornel]

Sandboxing of build scripts wouldn’t help at all — you’re still putting attacker’s code in your application and then executing it.

Rust doesn’t have any sandbox at runtime, and doesn’t have any serious protection against code doing nasty things (e.g. no_mangle or link_name can overwrite any function anywhere in the program).

[georgelyon]

Hypothetically, you could run the compiled application in a sandbox as well.

[johnthagen]

Sandboxing of build scripts wouldn’t help at all

Well, it would help a build server configuration, where the building machine doesn’t actually also run the built application. I can imagine scenarios where you might want to infect the building machine, but not necessarily inject yourself into every built binary. Maybe you just want your build script to steal GitHub creds or something.

But anyway, your point still stands that at some point you are putting trust in the code published on crates.io in the final binary.

[system]

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