Running Lima VMs from a nono sandbox, possible issues, request for feedback

[burnto]

I run each of my coding agents in separate sandboxes, and in some cases I've recently been giving them a throwaway Linux VM (via Lima) so it has its own docker compose, ports, and databases. I recently got this working under nono and wanted to share the process and ask for feedback about next steps.

Starting a VM with Lima's vz driver hits several Seatbelt denials that the typed capabilities don't cover. I used unsafe_macos_seatbelt_rules to allow them. The full set Lima needs to start a VM:

(allow mach-lookup (global-name "com.apple.Virtualization.VirtualMachine"))
(allow mach-task-name)
(allow generic-issue-extension
    (extension-class "com.apple.virtualization.extension.fuse")
    (extension-class "com.apple.virtualization.extension.rosetta-directory-share"))

(plus easy nono file access to ~/.lima and the image cache)

With those, the VM boots to READY inside the sandbox.

This raises a few things that might be worth separate issues. I wanted to ask here first in case any are already covered, or I've missed an existing mechanism.

1. Documentation. unsafe_macos_seatbelt_rules only appears in the JSON schema's description. It's not in nono profile guide, and I didn't find it on profile-authoring or internals/seatbelt. The schema description is good; it even says to prefer promoting common patterns to typed capabilities. So this is mostly about putting it where a reader will look.

2. Composition. I wanted to publish this as a pack so someone could add Lima support directly, but I don't think the rules can be composed. Groups are include/exclude only and don't carry an unsafe_macos_seatbelt_rules entry, and I didn't find a way to compose two profiles, so a user can't ask for "claude + lima." Is there a path I've missed? If not, a way for a pack to contribute raw rules, or for profiles to compose, would help.

3. A typed virtualization capability. The rules above are small and stable, and they match what the schema description says to promote. A capability covering the mach-lookup, mach-task-name, and the two generic-issue-extension classes would let people run VMs without the raw rules. The mach-task-name rule is the one I'm unsure about: it's broad, and I couldn't scope it to a single executable because the VM host process runs outside the sandbox. I'd be curious whether you'd want it narrower.

If there's a good way to package this up so it is reusable, I'd be glad to do it, but I don't see a "right" way to do it. Either way, happy to file any of these as separate issues. Let me know which are useful.

[lukehinds]

Hi @burnto , this is really cool and pleased you asked.

The best approach is to ship it on the registry.

If you take a look at https://github.com/always-further/nono-packs you will see how we configure packages. Each package has its own dedicated policy.json, so you can just add your existing policy there with the unsafe sandbox rules. Example https://github.com/always-further/nono-packs/blob/main/claude/policy.json

From there create a package.json: https://github.com/always-further/nono-packs/blob/main/claude/package.json

The package json allows you to move files into place you need for lima (if there are any) or add json , yaml values:

    {
      "type": "json_merge",
      "file": "$HOME/.claude/settings.json",
      "patch": "wiring/enabled-plugin.json"
    }

Once you're happy with it, head over to the registry.nono.sh and sign up for a user account, go to pushlish a package and get your package setup there. This will give you an example github action. Grab that, head back to the repo, add it as a workflow, and run it against a tag - we then just approve it and is available for anyone

Users from there on can do this:

nono pull burnto/lima and have your full profile locally, or even nono run --policy burnto/lima -- lima and if its not local, it will get pulled down.

You are then in full control of making changes, shipping releases and the registry acts as a secure mirror to make your package available to nono pull , you will also show up in nono search lima

More details here:

https://nono.sh/docs/cli/features/package-publishing

Please just message me in discord if you get stuck, I am more then willing to roll up sleeves and help you get it working.

[burnto]

Thanks @lukehinds - I'll look at publishing to the registry.

The design question I still have is that this would not be very helpful profile on its own. It's more like a capability that some profiles may want. I could imagine it as a group that could be added, or maybe as an allow-vms flag similar to --allow-launch-service and --allow-gpu flags?

Anyway, not to be solved immediately, and I may end up using a different VM approach anyway, but wanted to raise it. Thank you!

[lukehinds]

I think a group makes sense in the main inbuilt crates/nono-cli/data/policy.json