[Coding Guideline] Prevent OS Command Injection by sei-dsvoboda · Pull Request #370 · rustfoundation/safety-critical-rust-coding-guidelines

sei-dsvoboda · 2026-01-13T20:21:32Z

Closes #360

This is a new Rust rule based on the CERT Java rule IDS07-J.

netlify · 2026-01-13T20:21:37Z

✅ Deploy Preview for scrc-coding-guidelines ready!

Name	Link
🔨 Latest commit	`8bf8735`
🔍 Latest deploy log	https://app.netlify.com/projects/scrc-coding-guidelines/deploys/698b67f87a19bc0008aef8d0
😎 Deploy Preview	https://deploy-preview-370--scrc-coding-guidelines.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

felix91gr · 2026-01-16T19:07:37Z

@PLeVasseur should the bot not be assigning a reviewer automatically for pull requests as well? Or perhaps it's not automatic because it doesn't come from a template?

Anywho, here if I understand it correctly we should do the /r? command?

felix91gr · 2026-01-21T00:28:41Z

@sei-dsvoboda I've edited your original message to make Github close the original issue once this PR gets merged :)

github-actions · 2026-02-10T16:59:12Z

👋 Hey @alexandruradovici! You've been assigned to review this coding guideline PR.

Your Role as Reviewer

As outlined in our contribution guide, please:

Begin your review within 14 days
Provide constructive feedback on the guideline content, examples, and formatting
Iterate with @sei-dsvoboda - they may update the PR based on your feedback
When the guideline is ready, approve and add to the merge queue

Review Checklist

Guideline title is clear and follows conventions
Amplification section expands on the title appropriately
Rationale explains the "why" effectively
Non-compliant example(s) clearly show the problem
Compliant example(s) clearly show the solution
Code examples compile (check the CI results)
FLS paragraph ID is correct

Bot Commands

If you need to pass this review:

@guidelines-bot /pass [reason] - Pass just this PR to the next reviewer
@guidelines-bot /away YYYY-MM-DD [reason] - Step away from the queue until a date
@guidelines-bot /release [@username] [reason] - Release assignment (yours or someone else's with triage+ permission)

To assign someone else:

@guidelines-bot /r? @username - Assign a specific reviewer
@guidelines-bot /r? producers - Request the next reviewer from the queue

Other commands:

@guidelines-bot /claim - Claim this review for yourself
@guidelines-bot /label +label-name - Add a label
@guidelines-bot /label -label-name - Remove a label
@guidelines-bot /queue - Show reviewer queue
@guidelines-bot /commands - Show all available commands

plaindocs · 2026-02-18T15:18:11Z

Hey @alexandruradovici would you like to claim this review, or let someone else grab it?

alexandruradovici · 2026-02-18T15:39:53Z

src/coding-guidelines/program-structure-and-compilation/gui_J3K3ZqC8qoOn.rst.inc

+    :scope: module
+    :tags: injection,sanitization
+
+    Commands that are passed to an external OS command interpreter, like ``std::process::Command``, should not allow untrusted input to be parsed as part of the command syntax.


In my view, Command is actually performing this, the problem is when it is used with sh -c, meaning the Command runs the interpreter. I think one should never actually run the interpreter, rather than taking care of the parameters.

Hello, @alexandruradovici
I would agree that running the "sh" interpreter enables the command injection here. There are two general approaches: first, you would sanitize the arguments to prevent anything malicious from happening. Second, you use a less powerful command, such as invoking 'ls' directly without 'sh', or using fs::read_dir()...both compliant solutions use this second technique.

Are you suggesting a change in the wording, or in the code examples?

My suggestion is to use a more powerful command and advise agains running the interpreter (sh or equivalent) with any command. I would not relate it to the arguments, but to the what kind of commands should or should not be ran.

I wonder how we should do this.

Something that seems simple enough to do is a deny-list:

In the worst case, we would be denying non-injection-allowing programs. This is fine, as a failure on our labeling would not lead to a safety hazard.

An allow list would have the opposite problem: if we fail to account for injectability in a program we mark as "okay", we would be giving the 👍🏻 to a safety hazard. That's why I think an allow list would probably be bad to have.

For all other command-line programs, we give the user some criteria by which they might be able to know if running it is okay or not (in a non-ambiguous way)

That criteria could be something along the lines of...

"The program must not be turing-complete given its input": this would deny all possible injection mechanisms, but some valid programs could be denied as well. For example, a program that does arbitrary computation inside its own "isolated world" would be fine to run, but would not be allowed by this rule.

"The program must not be able to transitively spawn an arbitrary number of other processes": this would be a lot harder to assess, but feels a lot closer to what we want to avoid.

I would not relate it to the arguments, but to the what kind of commands should or should not be ran.

Ultimately, This is a Rust rule. I don't want the rule to blacklist some commands, because we can't make that blacklist complete. Too many shell commands + too many OS platforms. Creating a whitelist of 'benign' commands is safer, but no less Herculean a problem.

You also have the problem of when arguments are tokenized on Windows (see the BatBadBut vul).

We could try to limit commands in terms of Turing-completeness, but that also sounds like a huge rabbit hole. Which of these commands would we be forbidden from running: bash, python, sqlite3, jq, gcc ?

The only other option I see would be to forbid Commands entirely (at least for security-critical code). Allow exceptions only on an individual basis. Or allow Commands only in unsafe code.

github-actions · 2026-02-18T15:40:36Z