On 12/11/2016 06:21 AM, Reg Tiangha wrote:
> On 12/10/2016 09:10 PM, Reg Tiangha wrote:
> 
>> Ah, I see!
>>
>> OK, I think I may know what *might* have happened.
>>
>> I think the make script did try to do what it said in the instructions
>> here when it started to install the generated deb packages:
>>
>> https://www.qubes-os.org/doc/managing-vm-kernel/
>>
>> but I remember it throwing an error somewhere along the line saying it
>> couldn't find the kernel header files. But *that* was because it was
>> installing the kernel header file deb package afterwards; or in other
>> words, the gresecurity kernel header package wasn't installed yet at
>> that point in time. So maybe a step was missed.
>>
>> That said, I now have a properly booting debian 8 template with a
>> gresecurity kernel. What you need to do is this:
>>
>> After you follow the github instructions but before you reboot, run:
>>
>> sudo dkms autoinstall -k 4.8.12-coldkernel-grsec-1
>> sudo update-initramfs -u
>> sudo update-grub2
>>
>> which is essentially the final part of the "Installing kernel in Debian
>> VM" instructions. And then the machine should boot up fine when you
>> switch to the pvgrub2 kernel. Or, at least it did for me.
>>
>> Thanks for the hint!!
>>
> 
> And it looks like in the last 7 hours, they've bumped the kernel up to
> 4.8.13, modified the Debian template instructions, and temporarily
> pulled down the Fedora template instructions as well. So yeah, it's all
> still in flux. Gonna go recompile that 4.8.13 kernel now...
> 

OK, the weekend is almost over and I can't spend much more time on this.
So I thought I'd just wrap up the results of my (light) testing:


GENERAL:

- You'll want at least 4GB free to build the kernel.

- I can't seem to get it to work with a DispVM. I set my dvm image to
use pvgrub2 as its kernel, but every time it launches a new DispVM, the
new machine reverts to using my default 4.8.12 kernel. Actually, it
seems to resort to using all default values for number of CPUs and RAM;
changing those values seem to have no effect on spawned machines.

- I couldn't figure out how to get the RBAC stuff to work. I wanted to
use grsecurity's gradm tool, but it would always fail at the
installation portion saying that /dev/grsec did not exist (which it
didn't). I don't know how to create that device so for now, I've
reverted to enabling Apparmor or SELinux depending on the template.
You'll need to pass those kernel instructions through the VM's grub
config file, though. You can easily do that by creating a
/etc/default/grub file and adding a GRUB_CMDLINE_LINUX="apparmor=1
security=apparmor" or "selinux=1 security=selinux" line to it (you can
also set some other grub options like GRUB_TIMEOUT=0). Those modules are
included in the coldkernel and everything seems to work fine together.


DEBIAN 8:

- Seems to work fine as per the instructions. You can save yourself a
bit of grief beforehand by editing the install-deps section of the
Makefile and swapping the order it installs the kernel header package
and the kernel image package so that the header package is installed
first. Else, follow my instructions above (substituting the correct
kernel version that becomes recent when you try this) before you shut
down the VM.


FEDORA:

- I tried it on a Fedora 24 template. The instructions were pulled down
from the GitHub readme, and for good reason:  They don't work fully. The
Makefile will build a kernel image rpm and a kernel header rpm. However,
it neglected a kernel-devel package meaning that u2mfn module doesn't
get compiled at all. Personally, I would wait for the coldhak crew to
release updated Fedora instructions, but if you can't wait, here's what
you do (works as the time of this writing):

1) Install the Fedora packages as listed here (although there's probably
more than you need; I don't think you actually need the Development
Tools group, for example):

https://github.com/coldhakca/coldkernel/blob/6926736c830e994fc1e4f48df1a665ea78e29f94/README.md

2) Follow the Qubes Fedora instructions until just before the part about
making the grub config file.

3) Copy or move the linux-4.8.13 (or whatever version it is) directory
from the coldkernel directory to /lib/modules/4.8.13-coldkernel-grsec-1
and rename it to "build" as this is where the kernel source needed to
recompile the u2nfn module is expected to be found.

4) Recompile u2nfn by running:

    sudo dkms autoinstall -k 4.8.13-coldkernel-grsec-1

5) Regenerate initramfs by running:

    sudo dracut --regenerate-all --force

6) Create grub config file:

    sudo grub2-mkconfig -o /boot/grub2/grub.cfg

7) Shutdown template


WHONIX:

- Doesn't seem to work at all by default. The light on Qubes VM Manager
stays yellow and qrexec never connects. Couldn't figure this one out
although I didn't spend much time on it.


So that's all I've been able to figure out thus far. I haven't put this
kernel through its paces yet through standard usage though; only tested
to see if machines would boot and such. grsecurity already has test
patches for 4.8.14 so there'll probably be another update soon for those
who want to hold off for a bit.

Also, for anyone out there who actually has experience with grsecurity
kernels, any hints, tips or tricks on stuff to do next would be
appreciated. Is running it on its own better protection than using a
stock kernel, or do you really need that RBAC stuff working alongside it?

Finally:  What are the odds of this kernel being able to run in dom0 by
default? I wasn't brave enough to try considering I already burned an
entire weekend on this and can't afford to spend any extra time in case
something breaks. Would the procedure be the same as getting it to run
in a Fedora template? Or would something extra need to be done? I don't
know how the Qubes kernel differs from stock and coldkernel when it
comes to its patches. Otherwise, I'd be porting stock Fedora kernels to
use in dom0 for myself every time they push out a new one.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/o2kqgm%24k23%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Reply via email to