It depends on the cost. I think if your attacker has enough resources to get a Xen exploit, it’s highly likely they will also have a Linux exploit. You probably should find other security measures like a good firewall, instead of using Linux for protection.
opened 05:47PM - 05 Dec 17 UTC
T: enhancement
C: gui-virtualization
P: major
release notes
S: in progress
bounty
Although this is not a security issue due to the guid security model, there are … several advantages to using Wayland instead of X11:
## Advantages
### Higher performance
If allocations are on page boundaries, then we can use xc_map_foreign_rage (or the equivalent in the HAL) to map framebuffer pages directly from the client in the VM to the compositor in the guivm
### Lower memory usage
Since framebuffers are mapped instead of copied, the proxy wayland compositor should use less memory than xorg (On a VM which currently has 800M of RAM and two windows, Xorg is using 1/6th of the physical memory)
### Easier GPU acceleration support
AFAIR, a lot of OpenGL operations are preformed within the X server through the X OpenGL extensions. Simply forwarding these commands to the guivm would be dangerous, so we would need to process within the Xorg server then send the displaylist sometime before the end of processing and rendering. With Wayland graphics processing happens within the context of the application, and only a framebuffer is shared to the compositor. This means that we can simply attach GVT-g or comparable hardware graphics virtualuization to VMs without complex modifications to guid.
### Multiple dpi support
Wayland allows one to attach multiple displays with different densities, which is important for people with HiDPI laptops who want to use external displays. We can simply forward events for screen update to the client, although we have to deal with anonymity for anon-whonix, where position of multiple displays could be very revealing.
## Method
Wayland has two communication methods; Commands over a Unix socket, and shared memory buffers through a file descriptor with mmap. Commands, including shared memory setup and keyboard input, should be proxied through a client in the guivm and a stub compositor in the appvm. However, wl_shm::create_pool and wl_shm events should be intercepted so that the stub compositor and guivm wayland client both create file descriptors in their VMs, and the guivm maps a foreign range (or asks dom0 to do so, I'm not sure quite how that would work) to link together the contents of those two memory ranges.
## Doing this
I am starting work on forwarding Wayland between VMs. I would be interested in working on this for Google Summer of Code if the Qubes project decides to join.
zphaskqjrm:
apparmor
opened 06:14AM - 16 Jul 18 UTC
closed 11:43PM - 22 Sep 20 UTC
T: enhancement
C: templates
P: major
release notes
security
Technically, add `apparmor=1 security=apparmor` to `kernelopts`.
qvm-pref… s -s vmname kernelopts "nopat apparmor=1 security=apparmor"
For Debian templates I don't foresee any issues. For Whonix templates I foresee even less issues. Other templates, no idea.
What is the plan regarding 'VM kernel by default'?
(I am not advocating either dom0 or VM kernel. Just asking.)
Lately I’ve been re-examining my reasons for using Chrome OS despite the privacy concerns (Google per se isn’t in my threat model, but that doesn’t mean I want to feed them everything) and found my biggest reason is its use of verified boot, which ensures that only signed and approved code is executed. The root of this trust (not sure if correct terminology) is in a ROM.
When combined with powerwash and a small attack surface, this means that even if malicious actors do somehow punch through th…