Repository navigation
feat(env): optional passwordless sudo for the sandbox agent - #208
Conversation
40ae0f2 to
ae027d7
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #208 +/- ##
==========================================
+ Coverage 77.07% 77.22% +0.15%
==========================================
Files 47 47
Lines 3197 3219 +22
==========================================
+ Hits 2464 2486 +22
Misses 733 733
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
ae027d7 to
3b91964
Compare
Some tools (e.g. mock) need root for part of their work. Add an opt-in `sudo_access` flag that gives the sandbox's `agent` account - which already has the host user's uid - passwordless sudo, instead of running the whole shell as root. - prepare.sh: with AGENT_SUDO=1, installs sudo if missing and adds a NOPASSWD sudoers entry for the agent. Some images (e.g. Azure Linux) ship /etc/shadow with mode 0000, which sudo's PAM account check cannot read in a container, so it is made owner-readable. - LocalDockerEnvironment(sudo_access=...): passes AGENT_SUDO to prepare.sh, starts the container without no-new-privileges (sudo and setuid helpers such as mock's launcher need it), and fails fast if `sudo -n true` does not work. A READ_ONLY mount is allowed but logs a warning, since with sudo the agent could remount it writable. - The shell still runs as the host uid, so files the agent writes stay owned by the host user; files written through sudo stay root-owned (no ownership fix-up on stop). - MicroBot, ReadingBot, WritingBot, LogAnalysisBot, BrowsingBot, AgentBoss and CopilotBot accept sudo_access; a provided environment must already have sudo access. - Docs: "Sudo access" section. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
3b91964 to
c2f0033
Compare
| environment: Optional[any] = None, | ||
| additional_tools: Optional[list[ToolAbstract]] = None, | ||
| image: Optional[str] = None, | ||
| sudo_access: bool = False, |
There was a problem hiding this comment.
This might give sudo access all the sub-agents that AgentBoss creates
There was a problem hiding this comment.
It is expected. We don't have fine-grained control over the sub-agents as of now. We'll address this later along with improving overall AgentBoss experience.
| ) | ||
| ``` | ||
|
|
||
| - The agent's commands still run as your uid unless it explicitly uses `sudo`, so files it writes in a `READ_WRITE` mount stay owned by you. Files it writes through `sudo` are owned by root and are left that way. |
There was a problem hiding this comment.
what if the agent opens its own bash session using sudo bash and run the comamnds?
There was a problem hiding this comment.
This is true. When the Agent is given sudo access, all sorts of privileged things are possible. So, we included multiple warnings in this flow. The documentation assumes that the agent will be co-operative.
If the model becomes rogue, we don't have any real guardrail against it. This is applicable for all the privileged agents. Thus, the developer should be cautious before enabling this and the system where this agent runs shouldn't be critical for production operations.
Summary
Add an opt-in
sudo_accessflag that gives the sandbox'sagentaccount passwordlesssudo. Some tools, such asmock, need root for part of their work.The agent keeps running as the host user's uid. It only becomes root for commands it explicitly runs with
sudo. So files it writes in aREAD_WRITEmount stay owned by the host user, with no ownership fix-up needed. The default isFalse, which keeps today's behaviour.Changes
shell_server/prepare.sh: withAGENT_SUDO=1it:sudoif it's missing;NOPASSWDsudoers entry for the agent (/etc/sudoers.d/microbots-agent, mode0440);/etc/shadowowner-readable. Some images, such as Azure Linux, ship it with mode0000, which sudo's PAM account check can't read inside a container.LocalDockerEnvironment(sudo_access=...):AGENT_SUDOtoprepare.sh;no-new-privileges, becausesudoand setuid helpers (for examplemock's consolehelper launcher) need it. Withoutsudo_accessthe flag stays on, as before;sudo -n truedoesn't work in the agent's shell;READ_ONLYmount but logs a warning (see Security).agent. Files the agent writes throughsudostay root-owned; nothing is chowned when the environment stops.MicroBot,ReadingBot,WritingBot,LogAnalysisBot,BrowsingBot,AgentBossandCopilotBotacceptsudo_accessfor the environment they create. A providedenvironmentmust already have been created withsudo_access=True, otherwise they raiseValueError.Why sudo instead of a root shell
An earlier version of this PR ran the whole agent shell as root, and then had to chown every root-created file back to the host user. With sudo:
azldevexpects to run as a normal user in themockgroup, andmockescalates through its own setuid launcher.A follow-up PR adds
mock.yaml, which adds the agent to themockgroup, andazldev.yaml. With them,azldev comp rendersucceeds on the stock Azure Linux image as the agent, without sudo, and leaves no root-owned files in the repository.Security
With
sudo_access=Truethe sandbox becomes a guardrail rather than an isolation boundary.sudo, the agent has root with the container'sSYS_ADMINcapability and AppArmor unconfined, so it can mount filesystems and reach host-wide kernel interfaces.READ_ONLYmount as writable, or gain root on the host.no-new-privilegesalso makes setuid binaries in the image usable.The runtime warnings and the docs say this plainly. Enable it only for trusted tasks and trusted repositories, skills and instructions.
Testing
Unit:
AGENT_SUDOpassed toprepare.sh, thesudo -n truecheck (success, and failure stopping the container), theREAD_ONLYwarning, and no chown on stop.prepare.sh: the sudo setup only happens when requested.sudo_accessforwarding and the provided-environment check forMicroBot, all subclasses andCopilotBot.test_microbot.py::TestMicrobotUnitandtest_memory_tool_integration.pyalso occur onmainand come from my local environment.Integration: new
test/environment/local_docker/test_sudo_access.py, run on both stock images (DEBIAN_IMAGE,AZURELINUX_IMAGE):sudo_access=True, the agent runs as the host uid,sudo -n id -ureturns0, and a file it writes in aREAD_WRITEmount is owned by the host user;sudois unavailable.CI's integration selection, run locally: 25 passed, with no new failures compared to
main.Upcoming PRs in this stack
imageon the bots.sudofor the sandbox agent.rpm/mock/azldevtool definitions.session_optionsand skill tracking, so it can use a repository's agent skills.