-
Notifications
You must be signed in to change notification settings - Fork 409
Support deny_by_default for bash command tool #2999
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As the customer, I do wish the lookahead/lookbehinds could be supported but I accept the limitation given that deny_by_default is a reasonable workaround for my original goal of sandboxing my agent + letting it run freely within that sandbox.
The unit tests correctly show the principle of least privilege applied to toolSettings of execute_bash. Specifically, granting ls does not implicitly allow pwd (or anything more consequential).
Thanks for this excellent security improving PR! 🚀
| #[serde(default)] | ||
| denied_commands: Vec<String>, | ||
| #[serde(default)] | ||
| deny_by_default: bool, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for raising this! Another approach is configure the behavior to either : ask or just deny, being the default behaviour ask, although this accomplishes same.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I didn't do this because the default setting for a tool is to ask. so I am only adding deny support here. technically I can add approve to be default but there are other ways to do that already.
b7bd7c4 to
bb2f407
Compare
Problem: Customer wants to allow some commands and deny all other commands. To do that, today customer needs to add commands to allow list and use a negative regex in deny list to exclude other commands. That actually doesn't work. The deny list regex we use in Rust doesn't work for such negative look around. Given such pattern, the regex will not match anything. This is bad because customer "deny list" is now not matching anything. The 1st change is to fallback deny list to "*" when regex compilation fails, instead of ignoring not matching anything. The 2nd change is to introduce a boolean flag called "denyByDefault" so anything not in allowed list can be denied by default (instead of "ask" by default). With this flag, user can deny by default and explicitly add allowed commands to allowed list. This flag is OFF by default so it doesn't change default UX.
Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.