3) Grsecurity#How-To:_Qubes-Whonix → Fixed.
- Added note about dependencies for 4.9 Kernel
- Noted one can ignore grub error messages if they appear at sudo update-grub2 step
- Added entry for upgrading kernel builds
- Noted the signing key output should be checked against the one found on the coldhak blog (see below for query)
Query: Should we be doing another step using one of the keys at the link below instead for ‘verification’ checks?
[coldkernel/keys at master · coldhakca/coldkernel · GitHub]
The folder only lists torvalds.asc (for Linux kernels), spender.asc (for grsec patches) & I have no idea who greg.asc is and whether that matches the “coldhak signing key” or not. How do we check at the terminal?
The Tor Project instructions just refer to a website and checking the key matches for TBB, so I just put in the wiki the matching .png (coldhak website) in the interim. Is that safe enough or not?
4) Re: Sending Qubes-user forum a message about the 4.9 grsec kernel failure →
I was going to send an email to the Qubes-Users forums about the 4.9 kernel not working with grsec (that error far above), but I see SIGAINT has closed down. So, my old throw-away email can’t be used to send this query to:
qubes-users@googlegroups.com
I’ve found another provider for throw-away email, but they don’t allow posting for 24-28 hours when you register by Tor. So, we can wait a day or 2 to post, of if you’re keen, you might drop this into Qubes-User forums so we might get some advice earlier and I can fix up the wiki grsecurity entry if necessary(?). Anyway, this is what can be posted either way:
Greetings,
I am currently using Qubes 3.2 and have had success to date with running the 4.8 grsec kernel series (coldkernel) with Debian-8 AppVMs following the steps / advice outlined on the coldhak blog and github account.
I have recently tried to apply the 4.9.20 upgraded kernel to the Debian-8 TemplateVM and hit some problems.
I have followed the advice to install the latest qubes-kernel-vm-support package from the Qubes testing repository (for the Debian-8 TemplateVM) and avoided the error messages around “Bad return status for module build.” [https://github.com/coldhakca/coldkernel/issues/55] [Update qubes-kernel-vm-support package to include latest u2mfn.c for kernel 4.9 compatability · Issue #2691 · QubesOS/qubes-issues · GitHub]
The upgraded kernel successfully builds and the TemplateVM boots. However, the TemplateVM state light soon shifts from green to yellow. The qrexec.log and console.log look okay (no obvious error messages), but the guid.log shows a new cryptic error message I’ve never seen before:
ErrorHandler: BadAccess (attempt to access private resource denied)
Major opcode: 130 (MIT-SHM)
Minor opcode: 1 (X_ShmAttach)
ResourceID: 0x219
Failed serial number: 49
Current serial number: 50
Any attempts to run applications fail e.g. terminal. So, grsec groups can’t be set, paxtest can’t be run, and obviously it’s not functional, so there is no point creating a new AppVM based on it.
Can anyone who has the 4.9 grsec kernel up and running provide any advice on how to resolve this problem?
Regards
6) Template:Uwt_wrapper_deactivate_all_permanently → Fixed
I think you meant that these steps will deactive all wrappers AND remove stream isolation (it wasn’t clear to me). If that’s not the case, I’ll re-edit it. But this is what I came up (just changed the first paragraph):
The following instructions permanently deactivate all uwt wrappers and remove stream isolation for [[Stream_Isolation#By_uwt_wrapper|uwt wrapped applications]] system-wide. Consequently, all uwt wrapped applications revert to the default system networking configuration.
Moving on to the last point (5) re: Whonix Bot testing…
As follows:
