This is a proposal for a sandbox for ComfyUI. It does not cover all attack surfaces, but it is very simple to implement and a step up from the current state of security in ComfyUI on Windows.

High level design

We launch the Comfy server process with low integrity level. The integrity level manipulation can be done by calling the Win32 APIs directly in python using the pywin32 library. This

• prevents the server process from writing anywhere on the filesystem or registry unless the destination also has specifically allows low integrity access (which is almost nowhere).
• forces any child process to also have low integrity level, so this cannot be bypassed by launching a child process.

ComfyUI does require write access to a few directories to operate (output, temp, user, etc). We use icacls to lower the integrity level of these directories. This design works on all versions of Windows.

You can find an end to end working demo in this branch - follow the instructions in sandbox.py to launch ComfyUI. The out of the box experience should work, but we may need to change --allowed_dir parameters to make it work with customized setup / custom nodes.

You can also use sandbox.py directly with an arbitrary python script, which makes it easier to test:

$ pip install pywin32
$ echo "import os; os.system('cmd.exe')" > script.py
$ python .\\sandbox.py .\\script.py # this runs cmd in low integrity mode
# inside the low integrity cmd
$ echo “hello” > foo.py
Access is denied.
$ exit  # exit the sandboxed cmd
$ mkdir low-integrity-dir
$ python .\\sandbox.py .\\script.py --allowed_dir low-integrity-dir
# inside cmd again
$ echo “hello” > low-integrity-dir\\foo.py # succeeds

Attack surface not mitigated by this

• Custom nodes will still have read access to the entire filesystem, and full network access. They can send your Chrome history database to a remote location.
• Custom nodes run in the same process as ComfyUI and has access to the full python interpreter environment. They should be able to steal anything in the process memory, including any API keys.

Broad read access can be prevented by using AppContainers, which was designed to provide very strict security guarantees. It’s possible to run ComfyUI inside AppContainers, but the current big blocker there is that app containers cannot serve network traffic over localhost.

To prevent process memory access, custom nodes should ideally be executed in a separate process. That process could then be run inside an AppContainer, and we can talk to it using something other than HTTP over localhost.

Out of process sandboxed custom nodes would be a significantly more technically complex project (likely need ~1 quarter). I have a demo working of using app containers directly using the win32 APIs instead of having to package ComfyUI as an MSIX app, which removes a chunk of complexity.

Design details

Assuming we choose to go this route, there are some details to be hashed out:

• How the sandbox runs:
  • Currently the sandbox script is a parent process that launches a child python process with low integrity. It’s also possible to do all this in a single process - we can lower the integrity level of the current process. This means people can keep doing python main.py instead of running python sandbox.py main.py. This route feels preferrable for the production version.