On 12/11/2016 05:20 PM, Reg Tiangha wrote:
> 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.
> 

Or maybe I was wrong about SELinux. I just realized that it's never been
active. Perhaps it wasn't compiled into the kernel after all. Apparmor
still works fine under Debian, though.

-- 
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/o2kru6%244r7%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Reply via email to