Unofficial forward-ported grsec 4.9 Qubes kernel branch

[Reg Tiangha]

Just because the baton was dropped doesn't mean that others weren't
willing to pick it up.

There are a few groups now that are forward porting the last grsecurity
release (4.9.24) to work with newer kernels in the 4.9 branch. This is
the one that the Hardened Kernel Community Project links to:

https://github.com/minipli/linux-unofficial_grsec/tree/linux-4.9.x-unofficial_grsec

And the Dapper Linux project is trying to forward-port the patches to
4.11 (but it still doesn't compile properly; trust me, I've tried):

https://github.com/dapperlinux/dapper-secure-kernel-patchset


I've taken their work and created a test 4.9 Qubes grsec kernel branch
merging their patches with the Qubes/Xen patches here (the only one that
wouldn't merge was the mcelog patch so I commented it out; I'm too newb
to figure out how to adjust it to account for the changes that the grsec
patches make), if people wanted to play around with it:

https://github.com/rtiangha/qubes-linux-kernel/tree/devel-4.9-grsec


Some Notes:

- The resulting kernel-qubes-vm package as a VM kernel works *exactly*
the same as a coldkernel. So if you were running coldkernel in your VMs
before, you can save yourself a lot of time using this instead because
instead of installing a grsec kernel on each VM, all you have to do now
is install it once in dom0 and only point the VMs you want to use it.

- I haven't played with it too much yet, but the standard dom0 kernel
package boots, but you'll need to run paxctl to soften the protections
on various binaries and libraries for it to work 100% (paxctl -cm
/usr/bin/pulseaudio is definitely one of them), and maybe do some other
things as well. The problem is, Fedora doesn't have pax-tools in its
repository (I think; Debian definitely does), so you'll have to compile
those utilities yourself. The Dapper Linux project has a branch and
compile instructions on GitHub, but it's up to you to figure out how to
use them (there's lots of documentation on the web; the Arch and Gentoo
Linux grsecurity wikis are probably a good place to start):

https://github.com/dapperlinux/pax-tools


There's probably a risk in continuing to use a stale patch set as time
goes by, but if you're the type that believes a stale grsecurity patch
set is still better than the stock kernel configuration, there are
groups out there trying to keep it alive for as long as possible.


As for getting as many of those grsec patches merged upstream as
possible, that's where the Hardened Kernel Community Project comes in
and they're primarily concentrating on 4.11 for now. Their work is here:

https://github.com/thestinger/linux-hardened/


And I've created a 4.11 branch that merges in those patches (it's what
I'm currently running in dom0 on my personal machines at the moment, and
it seems to work fine) here:

https://github.com/rtiangha/qubes-linux-kernel/tree/devel-4.11-hard


If you just want a stock 4.11 experience, I've also created a branch
without the hardened stuff here:

https://github.com/rtiangha/qubes-linux-kernel/tree/devel-4.11


So for those who are bored with the stock kernels and want to try
something new (or need better hardware support than what 4.9 has), there
are a few more choices now.

[nicholas roveda]

I'm trying to build your port, but I,ve actually had to to some changes to `kernel.spec` because the script exits with an error at line 136: `%_sourcedir/check-for-config-changes .config.orig .config`.

So, here are my changes.

Original:

117 if [ -f %_sourcedir/config-%{version} ]; then
118 cp %_sourcedir/config-%{version} .config
119 else
120 cp %_sourcedir/config .config
121 fi
...
130 MAKE_ARGS="$MAKE_ARGS -C %build_src_dir O=$PWD"
131 if test -e %_sourcedir/TOLERATE-UNKNOWN-NEW-CONFIG-OPTIONS; then
132 yes '' | make oldconfig $MAKE_ARGS
133 else
134 cp .config .config.orig
135 make silentoldconfig $MAKE_ARGS < /dev/null
136 %_sourcedir/check-for-config-changes .config.orig .config
137 rm .config.orig
138 fi

My version:

117 if [ -f %_sourcedir/config-%{version} ]; then
118 cp %_sourcedir/config-%{version} .config
119 else
120 cp %_sourcedir/config .config
+++ cat /proc/config.gz | unzip > .config.current
121 fi
...
130 MAKE_ARGS="$MAKE_ARGS -C %build_src_dir O=$PWD"
131 if test -e %_sourcedir/TOLERATE-UNKNOWN-NEW-CONFIG-OPTIONS; then
132 yes '' | make oldconfig $MAKE_ARGS
133 else
134 cp .config .config.orig
+++ cp .config.current .config
135 make silentoldconfig $MAKE_ARGS < /dev/null
--- %_sourcedir/check-for-config-changes .config.orig .config
+++ %build_src_dir/scripts/kconfig/merge_config.sh .config .config.orig
137 rm .config.orig
138 fi

I don't know if this issue is related to my configuration or not, let me know.

[Reg Tiangha]

On 2017-08-23 9:01 AM, nicholas roveda wrote:
> I'm trying to build your port, but I,ve actually had to to some changes to `kernel.spec` because the script exits with an error at line 136: `%_sourcedir/check-for-config-changes .config.orig .config`.
>

Actually, if you mean that 'make rpms' fails by default, that's
intentional. It's because there isn't a 'config' file in the main repo
directory like there is in the other kernel branches.

The grsecurity kernel options include separate settings for 'host' and
'guest' depending on where the kernel is to be used. So for dom0, you
would configure a 'host' grsec kernel, and for a vm you'd configure a
'guest' grsec kernel.

With that in mind, there are two config files in the repo, config-guest
and config-host, with the only difference between the two is that single
option for host vs guest. It's not intuitive, but what you need to do is
copy one of those to be the main 'config' file for the repo before
running 'make rpms'

That said, I can't exactly tell *what* effect using one or the other has
on the kernel. No other kernel options change, so I don't know what it
does behind the scenes. Furthermore, running either kernel the other way
(ex. using a kernel configured to be a host kernel as a vm kernel
instead) seems to work fine. So at the end of the day, I suppose it
doesn't matter what configuration you use...?

The way I do it for my machine is I compile two kernels, using the
config-host file for my dom0 kernel, and the config-guest file for my
VMs. You can do this by installing the kernel rpm with the host
configuration, and the kernel-qubes-vm rpm with the guest configuration.
Or you can also change the rel number on the second compile to something
different and you can install both sets of packages at the same time
(although you may need to run rpm -ivh --force). "Many paths up a mountain."

So try reverting the check-for-config-changes script back to the way it
was and copying one of the kernel config files already included in the
repo to be the main 'config' file and run 'make rpms' and it should work
fine.

If you want to customize the config file, delete the 'config' file, run
'make rpms' and wait for the patching to complete (the process will also
stop when it can't find a 'config' file). Then copy the config file you
want to customize to the kernel-4.9.XX/linux-4.9.XX directory and name
it .config and then run 'make menuconfig' to go through the interface.
When done, copy back the new .config file to the root directory,
renaming it back to 'config' and then run 'make rpms'

Hope that helps!

[nicholas roveda]

Thanks for your answer!

I had already noticed that, in fact I'm using the host version as .config, but an error occurs at the line specified above.

With the trick of using the current configs and then override them with your file I've managed to build the rpms, but the sign fails (maybe it's the key related issue you commentes about in the spec file), so I wanted to ask you to check if it could be a problem with my system or packages.

[Sandy Harris]

At some point, these patches may become unnecessary & perhaps some of
them already are. There is ongoing work aimed at getting related
patches into the mainline Linux kernel.

Wiki: https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project
Mailing list: http://www.openwall.com/lists/kernel-hardening/

It is possible that in the long term helping with that work would be a
better use of time than the porting effort. On the other hand it seems
likely that the port is a good idea for now.

[nicholas roveda]

I think Reg has done a great job and the porting its a must go path to force the developers to throw away all the differences that slow down or prevent the develop of a secure system.

[Reg Tiangha]

On 2017-08-24 4:27 PM, nicholas roveda wrote:
> I think Reg has done a great job and the porting its a must go path to force the developers to throw away all the differences that slow down or prevent the develop of a secure system.
>

To be fair, I don't forward port anything; it's @minipli on GitHub
(https://github.com/minipli/linux-unofficial_grsec/releases) that does
the hard work. All I do is make it easy to use the existing Qubes kernel
build scripts to include and package it, which was the original intent
once the old coldkernel project became more mature, but unfortunately
ended when the grsec project stopped releasing patches to the public
with 4.9.24 (I do make one change to minipli's patches though, and
that's to remove his custom uname patch because a) something like
4.9.45.unofficial-grsec.qubes.pvops is ridiculously long and b) it
actually breaks the Qubes build scripts because it results in a version
mismatch and thus halts the compile).

But really, that branch is just a proof-of-concept; it really does
require the user to customize the kernel config and/or user space to
work properly, although it should work for the most part out-of-the-box.
I'm not sure yet if it can be completely trusted so I don't actually
recommend that people use it per se; for example, the grsec guy included
a binary firmware blob in the original grsec patches that was only
recently discovered. @minipli has taken it out of future patches, but
since the original patch set was never audited, who knows what else
might be in there? But for the people who've heavily invested in the old
coldkernel or in PAX in their VMs, at least this is a way they can
continue using it while still having a somewhat up-to-date kernel.

I'll double check that build script soon; it works on my machine, but
maybe what I have in my build VM isn't sync'ed with what I have on my
public account for the grsec branch. But I also only build on an FC23
VM; are people using something different (like FC24 or 25) to build on?
Because that might be it too.

[Reg Tiangha]

Just an FYI, but most of the KSPP recommended kernel options that aren't
enabled by default (that exist in the 4.9 branch; not all of them do
since others debut in 4.10+) are enabled in the 4.9 Qubes kernel that's
already been pushed out. It isn't much, but it's better than nothing and
if it's already included in there for free, then why not use it?

Also, later kernel versions (4.11+) have already included some of the
work from the Linux Hardened project, and if people are compiling newer
kernels, people can include the patches that haven't yet made it into
upstream from here in their own builds if they like:

https://github.com/copperhead/linux-hardened/releases

I used to keep track of that in my devel-4.11-hard branch, but when
newer kernel versions are released, the Linux Hardened project abandons
the old branch in favor of the newer branch and stops releasing patches
for it, even though the older version will be supported for another two
releases. So I just stopped doing it since the last 4.11 version doesn't
work with the last 4.11 hardened patch set, nor the first 4.12 patch
set, and it isn't worth it to migrate the new stuff since 4.11 is EOL
anyway, which is why my branch of that isn't as up-to-date as it could
or should be.

Instead, people can decide for themselves if they want to include them
in their kernel builds or not; it's easy to add your own patches with
the Qubes kernel build system (just add the path to the patch to the
series.conf file).

[nicholas roveda]

Thanks for all the details.

I've tested on the R4.0 rc1, so fc25, I'll try it soon on the R3.2 (fc23 and fc24), so we can crosscheck the script.

I saw both dom0 and vm rpms are generated, but is it better to generate different rpms for them with config-host and config-vm?

[Reg Tiangha]

Having the build script spit out separate rpms (or ideally, use
config-host for the kernel.rpm and config-guest for the
kernel-qubes-vm.rpm) would be ideal (but then figuring out how to handle
kernel-devel.rpms for both might be a challenge), but I really just
intended for that grsec branch to be a proof-of-concept using existing
Qubes build infrastructure. I wasn't intending on extending things (and
to be honest, I don't have the time), but if someone else wanted to take
it on, they're certainly welcome to!