[qubes-users] Re: Unofficial forward-ported grsec 4.9 Qubes kernel branch
On 2017-08-25 8:35 AM, nicholas roveda wrote: > 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? > 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! -- 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 qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/onpd6u%2425a%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Unofficial forward-ported grsec 4.9 Qubes kernel branch
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? -- 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 qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/9bbd1168-99c1-4d44-8733-4d0fff65f44d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Unofficial forward-ported grsec 4.9 Qubes kernel branch
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 rpmd are generated, but wouldn't be better to generate different rpms based on config-host and config-guest? -- 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 qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/8082f643-5ac7-464c-861b-2e2030fbd5f0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Unofficial forward-ported grsec 4.9 Qubes kernel branch
On 2017-08-24 9:23 AM, Sandy Harris wrote: > 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. > 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). -- 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 qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ono3s0%249hk%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Unofficial forward-ported grsec 4.9 Qubes kernel branch
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. -- 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 qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ono35q%2459o%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Unofficial forward-ported grsec 4.9 Qubes kernel branch
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. -- 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 qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5e907d70-409e-4afc-8134-ad1210c4821b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Unofficial forward-ported grsec 4.9 Qubes kernel branch
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. -- 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 qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CACXcFmmMRCotXA7RUa9ZiLH0zatVPfyCJ27sHdhwJ4_pMG2zhQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Unofficial forward-ported grsec 4.9 Qubes kernel branch
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. -- 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 qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/802ab249-c249-4bd5-b29d-1c9570b9028d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Unofficial forward-ported grsec 4.9 Qubes kernel branch
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! -- 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 qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/onlceu%24cdv%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Unofficial forward-ported grsec 4.9 Qubes kernel branch
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
118cp %_sourcedir/config-%{version} .config
119 else
120cp %_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
132yes '' | make oldconfig $MAKE_ARGS
133 else
134cp .config .config.orig
135make silentoldconfig $MAKE_ARGS < /dev/null
136%_sourcedir/check-for-config-changes .config.orig .config
137rm .config.orig
138 fi
My version:
117 if [ -f %_sourcedir/config-%{version} ]; then
118cp %_sourcedir/config-%{version} .config
119 else
120cp %_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
132yes '' | make oldconfig $MAKE_ARGS
133 else
134cp .config .config.orig
+++cp .config.current .config
135make silentoldconfig $MAKE_ARGS < /dev/null
---%_sourcedir/check-for-config-changes .config.orig .config
+++%build_src_dir/scripts/kconfig/merge_config.sh .config .config.orig
137rm .config.orig
138 fi
I don't know if this issue is related to my configuration or not, let me know.
--
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/43f8cc63-8b11-41a0-a9fc-a68fc13b4f9c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
