Posit Assistant: sandbox mode: only read within workspace?

[Dries-B]

Hi!

The documentation of sandbox mode says the following:

On macOS and Linux, commands run inside an OS-level sandbox. macOS uses Seatbelt (SBPL) to deny by default: writes are allowed only to the workspace and $TMPDIR, all network access is blocked, and sensitive paths (~/.ssh, ~/.gnupg, ~/.aws, etc.) can’t be read. Linux uses bubblewrap to the same end. Any command may run, but commands are isolated at the OS level.

Would it be possible to only allow reading of files within the workspace (and $TMPDIR)? This would increase my trust for Posit Assistant.

[juliasilge]

Thanks for reading the docs closely! This is a good question.

I don't think a strict workspace-only read rule would work directly. Sandbox mode restricts writes to the workspace and $TMPDIR but reads are a different problem. If we allowed reads only inside the workspace and $TMPDIR, almost no command would be able to start.

On macOS, a command must read its own binary, /usr/lib/dyld, and the dyld shared cache before it can run. On Linux, it must read the loader and the shared libraries. Both need /etc for CA certificates, DNS settings, and locale data.

Interpreters make this harder. A command that runs python, R, or node must read the toolchain. On a real machine that toolchain lives in many places: /opt/homebrew, ~/.pyenv, a conda environment, ~/.nvm, or an R library path in your home directory. Several of these paths are inside $HOME.

A literal workspace-only rule therefore turns sandbox mode into a mode where ls would fail.

I think the real need here is more like "do not read my personal files", not "do not read outside the workspace". On a development machine those two rules are very different, and the second one could be achievable, I believe. We could try something like:

• Allow reads of the workspace, $TMPDIR, the system roots, and the resolved toolchain paths.
• Deny reads of the home directory by default.
• Allow a small, named set of home directory paths that tools need, such as ~/.gitconfig.

This would invert the risky part. Today the home directory is readable, with a deny list for known secret paths. A deny list only protects the paths that we thought of. An allow list for $HOME also protects the paths that we did not think of. That is a real increase in what you can trust. What do you think, given your own use cases?

Maybe before you answer, I want to highlight some things for you:

1. Sandbox mode covers shell commands. It does not cover the R and Python code that Posit Assistant runs in the console, and you can get to any folder on your computer using R and Python.
2. A sandboxed command inherits the environment of the parent process. An API key in your environment is readable even when every sensitive file path is denied.

For the question I think you are really asking, which is how much to trust sandbox mode, these two limits matter more than read scoping FYI.

[Dries-B]

Ah, yes, I understand the necessity for reading other top-level directories like /usr and /etc... Indeed, limiting the access to the home directory seems more effective here.

[Dries-B]

Also, it is a very good point that you make, that Posit Assistant will have the possibility to access any file through R and Python anyway!

[Dries-B]

Regarding my own use case, or at least the way I am working: I am currently controlling access by doing development within a VM. In there, my agent can run in something like /yolo mode, to make it run without limitations.

Of what I understand from Posit Assistant, I think I am still hesitant to use it directly on my own machine. But maybe I could use it to work remotely on my VM through SSH? Just to be sure: would Posit Assistant in that case be able to infer information about my host machine?

[juliasilge]

I totally hear you on the hesitancy! The situation over remote SSH is mostly reassuring but not bulletproof. Over remote SSH, Posit Assistant runs on the VM, not on your laptop. It is a workspace extension, so Positron starts it in the remote extension host.

Shell commands, file reads and writes, and R and Python sessions therefore all stay on the VM. Sandbox mode picks its method from the platform of the VM, so a Linux VM gets the bubblewrap sandbox even when your laptop is a Mac. Model provider keys go to ~/.posit/ai/auth/data.json on the VM, and requests to the provider leave from the IP address of the VM. The prompt describes the VM, and it does not contain your user name or your host name.

At least three things still touch your laptop:

• Sign-in tokens from a provider such as Copilot stay in your laptop keychain. The remote extension asks Positron for a token when it needs one, and sign-in opens a browser window locally.
• If your ~/.ssh/config sets ForwardAgent yes for that host, Positron exports the agent socket into the remote extension host and into remote terminals. A command on the VM can then authenticate as you to other machines, although it cannot read your key files. Set ForwardAgent no to prevent this.
• Remote SSH is not a security boundary against an extension. Extensions are trusted code, and Positron gives every remote extension some APIs that your laptop serves. Posit Assistant does not really use them today, but that separation comes from the design, not from the operating system.

I think you can consider the remote SSH setup to give you most of what your VM already gives you. IMO the two things to really think about in terms of risk are agent forwarding and any credentials that you put on the VM itself.