Feature/ability to disallow certain shell commands

[bassie661]

A simple "if any" to be able to set disallowed shell commands in the .env

Background

Many times I encountered an agent getting stuck when starting a GUI application like vi or nano via the execute_shell command. Resulting in auto-GPT waiting endlessly until I either killed the command through another terminal session or I had to completely abandon the session with CTRL+C.

The GUI applications nano and vi or gedit are unnecessary as auto-GPT has the write_to_file and append_to_file commands to take care of that.

Changes

To be able to set the disallowed commands, I added the parameter "DISALLOWED_COMMANDS" to the .env.template.

Documentation

In the .env file you can set the DISALLOWED_COMMANDS, comma separated like DISALLOWED_COMMANDS=nano,vi,gedit

The variable DISALLOWED_COMMANDS can contain commands with spaces. The code that checks for disallowed commands isn't designed to handle complex commands with arguments, it's just looking for specific command names in the input string. If we need to handle complex commands, we may need a more sophisticated approach.

Test Plan

Tested with various goals which might triggered commands that we want to disallow, like nano, vi, gedit.

PR Quality Checklist

• My pull request is atomic and focuses on a single change.
• I have thoroughly tested my changes with multiple different prompts.
• I have considered potential risks and mitigations for my changes.
• I have documented my changes clearly and comprehensively.
• I have not snuck in any "extra" small tweaks changes

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment

Name	Status	Preview	Comments	Updated (UTC)
docs	⬜️ Ignored (Inspect)			May 22, 2023 8:47am

[ntindle]

Wait for #3669 #3663 #3653

[bassie661]

submitted

[p-i-]

This is a mass message from the AutoGPT core team.
Our apologies for the ongoing delay in processing PRs.
This is because we are re-architecting the AutoGPT core!

For more details (and for infor on joining our Discord), please refer to:
https://github.com/Significant-Gravitas/Auto-GPT/wiki/Architecting

[Wladastic]

I did a similar check, but also did a whitelist as well.
You could add an optional whitelist and those defaults I used, I just added a few bad bad ones, decide if you want those haha ( I didn't create a pr):

WHITELIST_COMMANDS = ["ls", "git", "cat", "grep", "find", "echo", "ps", "top", "df", "du", "uname", "whoami", "date", "uptime", "free", "curl", "wget", "tar", "zip", "unzip", "gzip", "gunzip", "bzip2", "bunzip2", "ssh", "scp", "rsync", "ping", "traceroute", "dig", "host", "nslookup", "ifconfig", "ip", "route", "netstat", "ss", "lsof", "kill", "killall", "pkill", "pgrep", "ps", "pstree"]
DISALLOWED_KEYWORDS = ["cd", "nano", "vim", "vi", "emacs", "rm", "sudo", "|", ">", "<"]

def validate_command(command: str) -> bool:
    tokens = command.split()
    if not tokens:
        return False

    if WHITELIST_COMMANDS and tokens[0] not in WHITELIST_COMMANDS:
        return False

    for keyword in DISALLOWED_KEYWORDS:
        if keyword in tokens:
            return False

    return True

[anonhostpi]

I think this would make more sense as a docker feature. There are user-security level methods to prevent this. Hard-coding in limitations doesn't seem like a secure practice. All it takes is for an agent/human to lookup workarounds around the prohibited commands in the repo's source code or the config files.

[Wladastic]

I think this would make more sense as a docker feature. There are user-security level methods to prevent this. Hard-coding in limitations doesn't seem like a secure practice. All it takes is for an agent/human to lookup workarounds around the prohibited commands in the repo's source code or the config files.

Those are supposed to be optional defaults in the .env, not hardcoded. Just like categories of commands that can be disallowed.

[anonhostpi]

Well the parser/filter for them is hardcoded. There are other security tools for this. I don't recommend implementing this feature this way.

I do think its a good feature, just a bad implementation.

All the agent has to do is read the .env file and it can come up with workarounds.

[Boostrix]

Other than that, there's more than just one blacklist/whitelist feature now for the shell execution feature.

[github-actions]

This pull request has conflicts with the base branch, please resolve those so we can evaluate the pull request.

[bassie661]

This one can be closed as it was taken care if with #3950