One thing we would not be able to take immediate advantage of in Qubes OS would
be the Subgraph-maintained grsec kernels. Even if we could package them properly
for use for the Qubes VMs (which should be easy), I'm not sure if the PV-nature
of our VMs would allow to get most benefit of things such as SMAP and SMEP,
potentially other protections...? But then again, Subgraph heavily use of
seccomp should provide significant hardening against the app->kernel attacks,
and for other attacks, specifically those coming from devices and networking and
usb stacks, we do have VM-isolated VMs.
Cheers,
joanna.
For future reference, it is worth noting that once Grsec templates are available in Qubes-Whonix within the next 6 months, the hardened Tor browser series is not going to play well with them.
Users will be required to run the default (stable) Tor browser instead.
The internet informs me that Grsec patches are incompatible with ASAN processes present in the hardened Tor browser series, due to PaX conflicts. Specifically:
PaX hard limits the maximum virtual memory size of a task in security/Kconfig:
ā¦ASAN needs only 2 TB, but it needs them at a very specific address (to mirror the addresses used by the programm in the lower 2 TB of the address space), so at least 8 TB address space is needed to fit all the mappings at their expected addresses.
The effect is that ASAN will fail when it tries to allocate a large range of virtual memory for its shadow memory. This will result in errors when trying to start the hardened Tor browser, like this one seen in Gentoo:
==5223==Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed correctly. ABORTING.
Addtional Pax flags will not work. The experts advise that it is still better to run the Grsec kernel, because ASAN is only really good for detecting (not preventing) memory corruption, whereas Grsec is designed to prevent exploitation.
A good technical guide - way, way above my paygrade - explaining the conflicts between Grsec and various memory clang sanitizers can be found here:
The instructions for building the GrSec kernel for Qubes Debian 8 TemplateVM is now on-line. Whonix templates will come later.
INSTRUCTIONS
Note: extremely alpha! It would make sense to try this with a cloned Debian TemplateVM, just in case you break things. The kernel has been bumped to 4.8.13, which is the latest version available at the time of writing.
I havenāt tried it, but Iām sure @Patrick wonāt be able to resist! Note the building of the kernel can take hours and you need to increase your template size to at least 10GB.
Edit: See updated and clear working instructions below.
We are currently working on supporting both Debian and Fedora TemplateVMs, however the below instructions assume a Debian 8 TemplateVM.
It is suggested that you create a dedicated Debian TemplateVM for experimenting with coldkernel. This support is very experimental, and may result in broken Templates.
Configuring Debian TemplateVM
First, change your max storage size to be 10GB (you can likely get away with anything over 4GB, however running out of disk space at the end of a build can be frustrating).
0.9a (the current release) was not released with Fedora support, and this was pulled from the README before the release was cut. The 0.9b release will be focused on Whonix as well as Fedora, however Whonix is currently taking priority. The goal is to push out both Whonix and Fedora support with 0.9b, however if Fedora support looks like it will take considerably longer, it will be bumped to 0.9c.
For providing binary packages, our goal is to offer grsec enabled binaries for Debian. Offering pre-built Fedora binaries is not currently in the roadmap, however it could potentially be added down the line.
There are some protections that come with compiling the kernel by hand, such as an actually random/functional GRKERNSEC_RANDSTRUCT1.
Tested and working instructions for the Debian-8 template are already in the wiki here:
The wiki instructions will need to preempt questions that grsec newbies (like me) will bring up in the future, so the same Qs arenāt answered over and over:
A new grsecurity patch has been released. How do I build with the new patch in my coldkernel TemplateVM?
This is not clear to me and Coldhak just says: run āmakeā (presumably make qubes-guest) with the new patch. Thatās not gonna cut it for usability of the masses.
I want to run my grsec AppVMs as usbVM, netVM, firewallVM and/or the proxyVM, but they wonāt connect or allow USB connections. What do I do?
It seems that config changes must be made to the coldkernel, so that more drivers are added to the kernelās .config file BEFORE the step of running āmake qubes-guestā (untested):
Iād be interested if anybody else has tried and been successful with this for networking and USB. If so, it should be recommended for experimenters.
I want to install the new grsec kernel version X.X.XX in my cold-kernel template, how do I do this?
There needs to be some general advice around how often the kernel should be updated. Qubes doesnāt update their base kernel for months at a time, but new grsec kernels seem to come out about every two weeks. It would be exhausting to build every time there is a new release.
Further, users will need to know which exact steps they are following to do this:
clone steps again?
just cd coldkernel, git-verify and git-checkout commands followed by running make-qubes-guest and installation steps?
Thanks for all the hard work! WillyPillow just pointed out to me today on the qubes-devel mail list that installing busybox and updating initramfs in Whonix is all you need to do to get it to boot with coldkernel, and I just discovered myself a few minutes ago that for whonixcheck to work, you need to add āuserā to group 9001 (and for tor-browser to work properly, you need to disable memory protection using paxctl just like you do for regular Firefox). I havenāt gotten much further than that in my testing, though. In the meantime while we all wait for 0.9c, any other tips are appreciated!
See screenshots here:
