Subject: Proposal: “Open with Isolated VM” integration for GNOME Boxes & Nautilus
Hi GNOME Boxes team,
I’m a GNOME user and long-time admirer of your work on Boxes.
I’d like to propose a feature that could significantly improve everyday security workflows: a context-menu option to open files or URLs in an ephemeral, isolated VM directly from Nautilus.
Motivation
Current use cases that require isolation (banking, opening untrusted files, browsing suspicious URLs, running unverified code) involve manually creating/configuring VMs. This is slow and discourages non-technical users from using virtualization for security.
Proposed workflow
Nautilus integration:
Add “Open with Isolated VM” to the “Open With” menu for files and to the right-click menu for URLs/links.
VM boot:
Launch a pre-configured, minimal OS image (GNOME desktop + basic apps) in Boxes.
Boot should be as fast as possible (ideally using snapshots or qcow2 backing files).
Content injection:
The selected file or URL is passed securely into the VM.
Files: mounted as a temporary shared folder or copied into a volatile filesystem.
URLs: opened in the default browser inside the VM.
Ephemeral lifecycle:
Upon VM shutdown, all changes are discarded and the image reverts to a clean state (like --transient in QEMU or Windows Sandbox).
Implementation considerations
Performance:
Use lightweight base images and snapshotting for sub-5s launch times.
Security:
Strict separation — no permanent shared folders, clipboard optional.
Dependencies:
Likely needs deeper Nautilus–Boxes integration and enhancements in libvirt/QEMU command handling for transient VMs.
Benefits
Security:
Reduces attack surface by isolating risky operations.
Accessibility:
Brings sandboxed workflows to non-technical users via a one-click action.
Competitive advantage:
GNOME could offer a user-friendly alternative to Windows Sandbox or Qubes-style disposables in a desktop-integrated, open-source way.
Hey! Thanks for sharing your thoughts about this. I have thought of similar things in the past.
I feel that if this is to be based on a specific OS base, such as GNOME OS, there’s no point in bringing Boxes+libvirt into the conversation. I would make this a standalone app that talks to QEMU directly. Boxes+libvirt is what makes the multiple-OS/preferences manageable. What you are seeking here is well defined VM.
Thanks for your quick thoughts and for considering the idea! It’s great to hear you’ve thought along similar lines.
Regarding the technical implementation: your suggestion of a standalone application talking directly to QEMU is indeed a very elegant technical solution for achieving a well-defined, ephemeral sandbox VM. We’ve also considered the development effort involved in building such a dedicated tool from the ground up, recognizing it might be more complex than adapting existing components. However, if this approach is ultimately the most streamlined and efficient way to deliver the core functionality, I’m completely on board with that.
My main concern, as a user, isn’t the underlying architecture, but solely the highest level of security combined with ultimate user convenience and seamless integration into the GNOME desktop.
The core value is in making powerful isolation accessible and intuitive for average users. The “Open with Isolated VM” workflow via the Nautilus context menu is absolutely key for this convenience. For security, ensuring the VM is always a clean, isolated environment (using snapshots or similar mechanisms) is paramount.
My primary goal is to empower average users with robust security through a simple, “one-click” secure workspace, regardless of the precise technical implementation details.
Thanks again for the feedback!
Best regards,
בתאריך יום ה׳, 14 באוג׳ 2025 ב-12:31 מאת Felipe Borges via GNOME Discourse <noreply@gnome.org>:
Thank you for your thoughts and for discussing the technical feasibility of this idea. I truly appreciate the feedback.
I understand that a dedicated, standalone application, while technically elegant, might represent a significant development effort. As a user, my primary goal remains to achieve the highest level of security through seamless, “one-click” integration within the GNOME desktop.
I’m keen to help move this idea forward. If building a new standalone tool is not feasible right now due to resource constraints, I am eager to learn what a good next step would be. Are there any existing tools, libraries, or core components that we could leverage to create a basic proof-of-concept? Or perhaps a different approach you would recommend for an external developer to get started on this?
I believe this feature would bring significant value to many users, and I’m ready to contribute in any way I can.
Hmmm. This seems like it straddles the line between Flatpak sandboxing and VM isolation somewhat. So I guess I have two questions:
Is there any advantage this provides that isn’t provided by Flatpak? (Or, perhaps, a new “isolated mode” for Flatpak, where it runs the application without connecting it to the user’s persistent state or the desktop portals.)
Could the isolated runtime be container-based instead, with the GUI of the container application exported back to the host display via PipeWire/remote-desktop? That sounds lighter than a full VM instance.
My main concern with anything VM-based is, then you have a situation where there’s this separate OS install (the one run in the VM) that has to be somehow kept updated & otherwise maintained so that it’s not missing security patches and the like. That’s a concern with container images, too, but containers have the advantage that downloading an updated base image and rebuilding the local container is just part of the normal workflow. With VMs it’s an extraordinary event.
Thank you for your thoughts and for discussing the technical feasibility of this idea. I truly appreciate the feedback.
Regarding your questions about Flatpak and containers, my primary goal is to achieve maximum security with ultimate convenience from a user’s perspective. I am not a developer, but I believe that a full VM offers a deeper layer of security than a container or Flatpak sandbox because it isolates the entire operating system environment, not just a single application.
I agree with your concern about maintenance. It is a major challenge for a VM-based solution. However, I believe we can solve this by looking at existing models. For example, some security tools and operating systems already have a built-in sandbox feature. Their solutions to the update problem are based on a reset mechanism or ephemeral mode, where the isolated environment is created from a clean, up-to-date image every time it is launched. This guarantees the user is always getting a secure environment without any extra effort on their part.
To make this simple for the average user, instead of a full desktop environment, we could have a minimal, dedicated VM that runs a modified, hardened web browser. This browser would open PDFs, media, and websites in a completely isolated and secure environment. This approach could offer the deep security of a VM with the simplicity of a one-click user experience.
I believe this feature would be a game-changer for regular users, and I’m keen to help move this forward.
As a user, my main concern is not the specific technical implementation, but the end result: maximum security with maximum convenience.
The idea of using a dedicated browser in a VM was just one suggestion to simplify the development and maintenance, but the core idea is about the “right-click context menu” and providing a secure, isolated environment for any type of file.
My primary goal is to empower average users with a simple, one-click way to handle suspicious files or links securely, regardless of how it’s implemented under the hood.
Sorry for the delay, just saw this. (#PROTIP: If you use the “Reply” button when replying to messages, other users will get notifications of your responses, rather than having to stumble across them days later, if at all.)
It’s worth considering, here, that your goal as stated is inherently contradictory. Maximum security is, by its nature, inconvenient. Maximum convenience is, by its nature, less secure.
I’m not saying it’s not possible to achieve a reasonable compromise between security and convenience, but to state “maximize both” as your goal is to reveal unrealistic goals — increasing one inherently decreases the other.
That’s less true than you might think, actually.
Your intuition about needing a hardened build of, say, the sandboxed web browser, is correct. Even in an isolated environment, security will always be diminished as long as the application itself remains insecure. Especially if it’s going to have access to the internet — and more and more applications are useless without access to the internet, these days.
Even ostensibly-“offline” applications like document editors or creative apps typically have the ability to download project assets, install extensions, and so on. The application will be varying degrees of less usable/useful, with that ability cut off.
So, most users wouldn’t want a fully isolated (as in blocked-from-connecting-to-the-network isolated) sandbox, even for their “secure” applications. (This is that whole convenience-vs-security conflict rearing its head again.)
It’s a big task locking down something as complex as a web browser. Any modern one is practically a mini-OS in its own right: It manages network requests and data transfers, launches independent processes (extensions and JavaScript workers) and provides communication channels between them, provides facilities for both short- and long-term organized data storage (caches and localStorage)… and lots more.
If you install something like that in a VM, it’s pretty nicely isolated, except for whatever permissions you grant it to access external data. (Network access, any account credentials you provide to it, etc.)
But if you install two applications into that VM, while they may be together in their isolation, they’re no longer isolated from each other at all. Two unsecured applications running with the same user permissions in the same OS runtime have free reign to examine and modify with each other’s files, change each other’s settings, and so on. So unless you want to run each application in its own separate VM (unrealistic on all but the most capable of current hardware), the security of the system as a whole just took a big dip.
Flatpak can actually do you one better, there.
A Flatpak-sandboxed application defaults to fully isolated. Not just from the system and from the user, but even from each other.1 Any access a Flatpak application has to anything outside of the sandbox — the network, the user’s files, to services like the notification system, keyboard shortcuts, screen sharing/recording, etc — has to be explicitly granted, either by configuration in the application manifest, or interactively from the user in response to a portal request.
Most applications are built with access to at least some external services. (Again, it’s the usual security-vs-convenience tradeoff.) But a theoretical “secure” application build that doesn’t apply built-in permission to access things like the user’s personal files, AND doesn’t grant access to the desktop portals that would allow interactive requests for access, may actually be better-isolated than if it’s running in that VM, because it also can’t see any of the other Flatpak applications installed alongside it.
(Unless it’s granted permission to communicate with some other app. Which is possible in Flatpak, but that permission is individual, narrow, explicit, and specific.)
By default a Flatpak app is locked out of anything other than read-only access to its own bundled application files, plus (also read-only) access to the runtime services it’s built on top of. (Flatpak runtimes are roughly equivalent to a VM’s OS image.)
For application-level security, that may even beat out a VM in terms of isolation. Sure, its network traffic is flowing through your system, but that’s equally true of the VM as well. Sure, its data is technically stored on the host filesystem, but that’s equally true of the VM as well. (Where do you think a VM image lives?) The greater or lower-effort isolation of a VM is… largely imaginary, when it comes right down to it. The only area where a VM can really claim a win is that its isolation is more intuitive. But if that matters, we’re right back in the realm of security theater.
Notes
(The hard siloing of Flatpak apps is actually one of my chief complaints about it, conceptually. In the name of security [theater], it completely rejects the UNIX philosophy: Many small tools, each with a narrow and well-defined purpose, working together towards shared goals.
Every time you run a command pipeline at a shell prompt, you’re trusting each one of those commands with full access to your data in a near-zero-security environment. Yet somehow, instead of being pants-wettingly terrifying, for the past 40+ years that’s worked out pretty OK for us.
Flatpak is an extremely heavy-handed fix for an almost entirely theoretical problem. But, nobody ever got anywhere arguing “against” “security”.)
Thank you again for your detailed response. Your analysis has prompted a lot of further thought on my end.
I am now considering two main paths to achieve the goal of a one-click, secure environment for handling untrusted files. Each path has its own set of challenges that need to be addressed.
Option 1: The VM-based Approach
The core idea here is a simplified, disposable VM that launches from the Nautilus context menu. This approach offers a powerful, intuitive sense of complete isolation from the host system.
Challenges of this approach:
“Update Mechanism:” How to ensure the VM is always up-to-date without user intervention.
“System Overhead:” The VM might be too heavy and slow to launch for a quick, one-off task.
“Internal Security:” As you pointed out, a VM offers limited security if it runs multiple insecure applications.
Option 2: The Flatpak-based Approach
This approach leverages Flatpak’s strong isolation capabilities. The core idea is to create a new application that uses a dedicated Flatpak sandbox with a “reset mechanism”. Every time it launches, it would provide a clean, fresh environment, and all changes would be discarded upon closing.
Challenges of this approach:
“The “Reset” Mechanism:” This feature is not a standard part of Flatpak. It would require custom development to ensure the sandbox is completely cleared.
“Kernel Security:” While extremely rare, there is a theoretical risk of a kernel-level exploit, which could break out of the sandbox.
Given these challenges, which path do you think is more feasible to deliver a polished, ready-to-use product for the average user?
Your input is invaluable, and I’m eager to hear your thoughts on the best way forward.