jollheef / appvm

Nix-based app VMs

Nix application VMs: security through virtualization

Simple application VMs (hypervisor-based sandbox) based on Nix package manager.

Uses one read-only /nix directory for all appvms. So creating a new appvm (but not first) is just about one minute.

Installation

See related documentation.

Usage

Search for applications

$ appvm search chromium

Run application

$ appvm start chromium
$ # ... long wait for first time, because we need to collect a lot of packages

Synchronize remote repos for applications

$ appvm sync

You can customize local settings in ~/.config/appvm/nix/local.nix.

Default hotkey to release cursor: ctrl+alt.

Shared directory

$ ls appvm/chromium
foo.tar.gz
bar.tar.gz

Close VM

$ appvm stop chromium

Automatic ballooning

Add this command:

$ appvm autoballoon

to crontab like that:

$ crontab -l
* * * * * /home/user/dev/go/bin/appvm autoballoon

appvm's Issues

Qemu error: PCI slot 2 function 0 not available for qxl-vga

Hey,
when trying to use appvm start chromium I get following error:

2022/05/20 17:32:19 internal error: process exited while connecting to monitor: qemu-system-x86_64: -fsdev local,security_model=passthrough,id=fsdev-fs0,path=/nix/store,readonly: warning: short-form boolean option 'readonly' deprecated
Please use readonly=on instead
2022-05-20T15:32:18.834702Z qemu-system-x86_64: -device {"driver":"qxl-vga","id":"video0","max_outputs":1,"ram_size":536870912,"vram_size":536870912,"vram64_size_mb":0,"vgamem_mb":256,"bus":"pci.0","addr":"0x2"}: PCI: slot 2 function 0 not available for qxl-vga, in use by e1000,id=(null)

I tried to patch xml.go but without success :(

Move out libvirt xml from appvm.go

Better to write serializer from golang struct or use some libraries for work with libvirt.

Dynamic screen resolution in application vm's

Currently (https://github.com/jollheef/appvm#generate-resolution) screen resolution inside vm does not change when window resized.

Current implementation with dynamic scaling (from virt-viewer) is a good, but it's can be better.

Better automatic memory ballooning

Current implementation (
https://github.com/jollheef/appvm#automatic-balloonin) does not handle very fast resizing of available memory, because it runned every minute (by cron).

It's just a proof-of-concept, and need to be replaced with something more precise.

NixOS module

Write a NixOS module for the appvm.

Like simple-nixos-mailserver.

torbrowser appvm: block all connections outside tor from VM

Currently It works on application level.

It's will be much more better if we block all connections on iptables level (e.g. use user id for filtering etc.) inside VM.

Configuration file

There are some command line (e.g. --min-memory and --adj-memory for autoballooning, also --networking-model in #20) switches that are better to have also in the configuration file that not introduced yet.

So the idea is to have a configuration file that will set all Default("...") in parameters for kingpin.

Rewrite for use go regex

appvm/appvm.go

Line 210 in 959e6e6

reginfo, _, _, err = system.System("sh", "-c", "cat result/bin/run-nixos-vm | grep -o 'regInfo=.*/registration'")

macOS support

Libvirt available in home-brew, and qemu on macOS since v2.12 (24 April 2018) supports Hypervisor.framework.

Which means it's possible to port appvm to macOS.

Automate installation

Snap/deb/rpm or just good script or tool (in golang!).

Patches fail with latest virt-manager version

README: Compare with Qubes OS?

Thank you for publishing this really cool project.
It seems to be inspired on the AppVMs in Qubes OS.
I would like to know what are the differences between this implementation of the idea and Qubes OS, and what is the maturity status of this project? (Or, similarly, why did you reimplement it?)
How would I recognize a spoofed window from a compromised appvm?

nixos 20.03: permission problems for libvirt connection

I did a fresh install of nixos today, and I'm currently a bit out of ideas. I followed the installation procedure without problems, but later:

appvm start firefox

results in:

2020/07/27 19:03:43 authentication required

The error is thrown at that line:

appvm/appvm.go

Line 507 in d9c6519

log.Fatal(err)

I've tried to tweak libvirt and polkit configuration, but to no avail (usual advice on the internet is to change unix_sock_group, but it doesn't help here. Nixos uses polkit auth by default, but polkit should allow my user too. My user is a member of libvirtd as it should). Does anyone know why (apparently) appvm can't read libvirt's socket?

I can run virsh -c qemu:///system list as my user and it works correctly.

When I use sudo:

sudo appvm start firefox

It has no permission problems and almost works correctly, except it has a different error (trace: Duplicate uid 0). I could probably work around it, but I suppose sudo is not the solution to everything and I prefer to find the underlying problem.

add to group libvirt?

Hi, should "libvirt" be "libvirtd"?

Regards.

Can't start appvm

Ubuntu 16.04

v@v-To-be-filled-by-O-E-M:~$ appvm list
Started VM:

Available VM:
	 chromium
	 firefox
v@v-To-be-filled-by-O-E-M:~$ appvm start chromium
trace: Default graphical session, 'xmonad', not found.
Valid names for 'services.xserver.displayManager.defaultSession' are:
  none+xmonad

error: The option value `services.xserver.displayManager.defaultSession' in `/home/v/.nix-defexpr/channels/nixpkgs/nixos/modules/services/x11/display-managers/default.nix' is not of type `session name'.
(use '--show-trace' to show detailed location information)
2020/01/14 15:46:28 <nil> [] []
2020/01/14 15:46:28 ret code: 1, out: [], err: []

Wayland support

Currently appvm uses X11/Xorg. This issue is for experimentation with Wayland, with eventual goal being to have optional Wayland support without Xorg on the guest, and maybe to pass windows to the host more directly with waypipe.
Possible approaches

• cage (or other simple wayland compositor)
  Cage is a simple compositor that starts a single application full-screen and quits as soon as that application quits.
  Problems: no support for automatic resizing or other features of SPICE. It's a deal-breaker, as the almost-native experience that we thrive for is ruined by the need to capture pointer and keyboard, and the window does not resize correctly.
  Possible solution: write a daemon that reacts to SPICE events.
  Things done

  • mingetty autologins user, cage starts from loginShellInit
    Problems: not very fast, feels bodgy
  • cage replaces getty, logs in via a PAM module (as suggested upstream)
  • Make cage understand SPICE (either by patching cage or by writing a shim`
  • Find another wayland compositor that already knows SPICE

• GNOME3
  Gnome3 supports SPICE natively or maybe not, see the following

  • https://www.reddit.com/r/qemu_kvm/comments/d2yqy6/anyone_had_problems_resizing_guests_with_spice/ (clearly suggests that gnome on wayland doesn't work with SPICE)
  • https://bugzilla.redhat.com/show_bug.cgi?id=1266484 (clearly suggests that it does work)

  Potential problems: SPICE not working, very heavy, not sure if it can run a single full-screen app without all the fuss (see https://help.gnome.org/admin/system-admin-guide/stable/lockdown-single-app-mode.html.en, not sure if this is for wayland or for X)
  Things done:

  • GDM starts a wayland gnome kiosk session
    Problems: really heavy, might be buggy
  • dbus-launch gnome-session from loginShellInit
    Problems: might not support SPICE or whatever

• waypipe without compositor
  It might be possible to run waypipe on a guest without having a compositor at all. This would solve most of our problems with SPICE, since all of the window management now happens on the host. I have not looked into waypipe, so maybe I'm wrong, but this looks like the most elegant and "correct" solution of them all.
  Problems: might not actually run without a compositor, might be slow, requires networking between guest and host, might be insecure
  Investigation process:

  • waypipe can run without a compositor (tested with waypipe ssh headless-server konsole, where headless-server only has waypipe and konsole installed)
  • Figure out how host and guest can talk to each other
  • Figure out how to make guest's waypipe server talk with host's waypipe client (using -s argument and socat)

  Things done:

  • Run a guest with waypipe and the application installed, then run waypipe ssh user@guest application from the host (we have to figure out credentials)
  • Run waypipe client on a host, run guest with waypipe server CMD, make them communicate (I like this solution the most of them all)

insecure use of tmp

An attacker can replace this file with a symlink and trick the user into overwriting a different external file:

appvm/appvm.go

Line 209 in fd224db

qcow2 = "/tmp/.appvm.fake.qcow2"

Therefore it is better use https://golang.org/pkg/io/ioutil/#TempFile which is not vulnerable to these race conditions

Permission problems

appvm start chromium
/nix/store/gr8x944bv3cwhk4i5751yhbqix1b16lh-nixos-vm
2020/07/14 22:20:52 internal error: process exited while connecting to monitor: 2020-07-14T21:20:52.185266Z qemu-system-x86_64: -blockdev {"node-name":"libvirt-1-format","read-only":false,"cache":{"direct":false,"no-flush":false},"driver":"qcow2","file":"libvirt-1-storage","backing":null}: Could not reopen file: Permission denied