The installer seems to work. Currently using kernel 3.2.67-grsec. Will come back in T210. whonixcheck and sdwdate are working with AppArmor disabled.

Licensing sorted out:
https://github.com/rickard2/grsecurity-Debian-Installer/commit/7ba1695c20b573d5b979deeb60205c4cc7f122ad

Done with initial packaging:

• https://github.com/Whonix/grsecurity-installer
• https://github.com/rickard2/grsecurity-Debian-Installer/pull/15

In T203#2744, @troubadour wrote:

The installer seems to work. Currently using kernel 3.2.67-grsec.

Are you sure grsecurity is really active? I've run the script with debugging and saw that applying the patch failed. The script succeeded anyhow and installed a kernel that included grsec in its name. But checksec.sh reports, that grsecurity is disabled. Did you make sure grsecurity is enabled using checksec.sh or some other means?

whonixcheck and sdwdate are working with AppArmor disabled.

It's possibly not because of grsecurity, but because a newer kernel version is being used. So these are possibly AppArmor issues due to a newer kernel version unrelated to grsecurity.

Using that script you need to manually enable grsecurity using menuconfig. Otherwise the kernel is named grsecurity but doesn't have grsecurity enabled. I succeeded building a grsecurity enabled kernel (as per checksec), but it cannot open a graphical KDE desktop yet and there is also a vbox guest additions specific issue (https://www.virtualbox.org/manual/ch12.html#idp100531824).

Yes, the kernel name was appended with -grsec but it was not enabled.

Perhaps a non related issue. Built a kernel after enabling grsec in menuconfig. It did not run because of (apparently) some virtualbox issue (selected Virtualbox guest in the menu). I purged the guest additions. No change with the grsec kernel, but after rebooting with 3.2.0-4-686-pae, kdm does not start automatically. sudo kdm returns nothing.

After reinstalling the guest additions, Workstation boots normally.

linux-grsec now in Debian unstable

https://twitter.com/benhutchingsuk/status/684437715941744640

For future out of the box support efforts we would only have to look into maintaining paxctld exception list. A less major task than developing/maintaining grsec-installer. Also changes like default apt-pinning suport would be needed because grsec kernels will stay exclusively in Debian unstable.

What is the status of https://www.whonix.org/wiki/Grsecurity? Tested / working in Whonix?

In T203#7843, @HulaHoop wrote:

linux-grsec now in Debian unstable

https://twitter.com/benhutchingsuk/status/684437715941744640

Nice!

For future out of the box support efforts we would only have to look into maintaining paxctld exception list. A less major task than developing/maintaining grsec-installer.

Would you create/maintain that list?

Also changes like default apt-pinning suport would be needed because grsec kernels will stay exclusively in Debian unstable.

Not a problem as long this is a user documentation only thing. The Apt-Pinning wiki template looks good and unlikely to cause issues.

Let's implement this a user documentation only thing first. Have some wider testing. [Write a blog post to encourage testing.]

Can you get the Debian linux-grsec package way to use this in Whonix documented/tested?

When that works... Later for more automation / simplification we could reconsider Whonix Dev/APT_Pinning and perhaps create a package that simplifies this.

Would you create/maintain that list?

Yes. I am thinking about taking the Arch paxctld list and adjusting executable paths for Debian's choices. As it is now, the grsec package cannot work with Xorg and so that will need to be sorted out first.

Can you get the Debian linux-grsec package way to use this in Whonix documented/tested?

I will post updates after testing.

Paxrat suggested by Jacob makes exceptions handling easier to manage across package upgrades so they don't break after the first apt update is downloaded:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605090#487

https://github.com/subgraph/paxrat

incorporating this package in Whonix is essential for a long term solution.

Debian packaging:
https://github.com/subgraph/paxrat/issues/1

Can you write/post draft/submit an Debian RFP (Request for Package) for paxrat please?

(More info, what should go into it, compare with this one: https://github.com/theupdateframework/tuf/issues/263)

First I applied the Apt-pinning instructions (https://www.whonix.org/wiki/Template:Apt-Pinning) then:

sudo su -c "echo -e 'deb http://security.debian.org unstable/updates main contrib non-free\ndeb http://ftp.us.debian.org/debian unstable main contrib non-free' > /etc/apt/sources.list.d/debian-unstable.list"

sudo apt-get install linux-image-4.3.0-1-grsec-686-pae linux-grsec-support-4.3.0-1 linux-grsec-base paxctl

All relevant grsec packages:

linux-grsec-source-4.3 - Linux kernel source for version 4.3 with Debian patches
linux-grsec-support-4.3.0-1 - Support files for Linux 4.3
linux-headers-4.3.0-1-common-grsec - Common header files for Linux 4.3.0-1-grsec
linux-headers-4.3.0-1-grsec-686-pae - Header files for Linux 4.3.0-1-grsec-686-pae
linux-image-4.3.0-1-grsec-686-pae - Linux 4.3 for modern PCs, Grsecurity protection
linux-grsec-base - Linux image base package, grsec featureset
paxctl - new PaX control program for using the PT_PAX_FLAGS marking

List of changes an install triggers. Note gradm2 is installed as a dependency:

The following extra packages will be installed:
  firmware-linux-free gradm2 irqbalance libc6-i686 libnuma1 pax-utils
Suggested packages:
  linux-patch-grsecurity2 linux-doc-4.3 debian-kernel-handbook
The following packages will be REMOVED:
  xserver-xorg-input-all xserver-xorg-input-vmmouse
The following NEW packages will be installed:
  firmware-linux-free gradm2 irqbalance libc6-i686 libnuma1 linux-grsec-base
  linux-grsec-support-4.3.0-1 linux-image-4.3.0-1-grsec-686-pae pax-utils
  paxctl
0 upgraded, 10 newly installed, 2 to remove and 13 not upgraded.
Need to get 35.5 MB of archives.
After this operation, 129 MB of additional disk space will be used.

Paxrat without packaging needs some work to get running like figuring out the correct paths for the binaries and configuration files.

sudo apt-get install golang

Thats how far I got yet and I'll make a request draft.

ETA for subgraphOS alpha: https://twitter.com/attractr/status/684075394509717505

Almost there, SGOS alpha first week of March.

Here it is. There are some blanks that I need help filling and important things like licensing need attention.

• Package name : paxrat Version : 1 Upstream Author : Name <info@subgraph.com>
• URL : https://subgraph.com/
• License : ? Programming Lang: Go Description : PaX exception daemon for Debian packages.

The newly packaged grsec kernel makes it easier for anyone to run a more secure kernel. However some major packages like Iceweasel/Tor Browser, JIT interpreters and main components of Gnome and KDE require PaX exceptions because they are not compatible with memory protection features of the enhanced kernel.

Paxrat from the SubgraphOS project is a daemon that maintains and applies rules from an exception list. It has dpkg hooks for taking care of binaries even when updated.

Paxrat is implemented in GoLang and is simple to use.

Also a Grsecurity kernel maintainer are interested to have paxrat packaged. [1]

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605090#487

Asked for comments support:

https://github.com/subgraph/paxrat/issues/2

What blanks?

HulaHoop (HulaHoop):

It has dpkg hooks for taking
care of binaries even when updated.

Really? Sure? Code? Not sure if this comment by Jacob was
misinterpreted. It would be useful if there were dpkg hooks.

What blanks?

I have no idea what their licensing for this and other packages in Subgraph is.

Who do I put as the upstream author? What email should I use - is the address for general contact enough?

What mail list do I post to?

Sure?

Yes. This is very much what paxd does except its another project and coded in C, Also take a look at the original comment:

paxctl one off runs isn't great for a full solution.

paxrat improves on this as package updates and other things can stomp
on pax related xattributes. paxrat seems very very useful in this
context - we get configuration files as well as dpkg hooks.

Until now there is no license file and no license information in the source files either. So for the moment it cannot be considered Libre Software and must be considered proprietary. Please open an issue on paxrat github.

Cannot fill-out upstream author yet either because it's not declared either. Please open an issue on paxrat github.

Forget the comment. You need to know where to find the code for the hooks. That paxrat repository does not include any dpkg hooks nor claims to ship any of them. These are usually shell scripts, easy to identify. It only writes "Runnable as a hook to a package manager such as dpkg". Yes sure. Any tools is runnable as hook to dpkg. Doesn't mean the hook has been written yet. Looks to me those still have to be written.

Where to send [and how (!) - the header does the magic] - is documented here:
https://wiki.debian.org/RFP
And here:
https://www.debian.org/devel/wnpp/#l2

https://github.com/subgraph/paxrat/issues/4

I see. Do I open a ticket for adding the dpkg shell scripts? Do we just wait?

Feature request won't harm probably.

Dpkg hooks request filed: https://github.com/subgraph/paxrat/issues/5

Source package feedback:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605090#572

Upstream has sorted out a lot. Licensing, dpkg hooks and config file comments (pull request by Alexey Derlaft).

Requested release and signed git tags:
https://github.com/subgraph/paxrat/issues/6

Updated the RFP proposal.

To: submit@bugs.debian.org
Subject: RFP: paxrat -- PaX exception daemon for Debian packages

Package: wnpp
X-Debbugs-CC: desktops@secure-os.org
X-Debbugs-CC: corsac@debian.org
X-Debbugs-CC: jacob@appelbaum.net
X-Debbugs-CC: whonix-devel@whonix.org

* Package name: paxrat
  Version         : 1
  Upstream Author : David McKinney <mckinney@subgraph>
* URL             : https://github.com/subgraph/paxrat
* License         : GPLv3
  Programming Lang: Go
  Description     : PaX exception daemon for Debian packages.

The newly packaged grsec kernel makes it easier for anyone to run a more secure kernel. However some major packages like Iceweasel/Tor Browser, JIT interpreters and main components of Gnome and KDE require PaX exceptions because they are not compatible with memory protection features of the enhanced kernel. 

Paxrat from the SubgraphOS project is a daemon that maintains and applies rules from an exception list. It has dpkg hooks for taking care of binaries even when updated. [2]

Paxrat is implemented in GoLang and is simple to use.

Also a Grsecurity kernel maintainer are interested to have paxrat packaged. [1]

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605090#487
[2] https://github.com/subgraph/paxrat/blob/master/etc/apt/apt.conf.d/70paxrat

Awesome.

There is also a linux-grsec backported kernel package available for Jessie which means we don't have to mess with apt-pinning or a dependency mess to build the source one optionally.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605090#582

EDIT:

Apt-pinning may be still needed for jessie-backports but the dependency problems will be gone.

Want to post the RFP?

RFP sent.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810479

Latest post by Yves on status of grsec support and comments on the default settings chosen for the kernel pacage.

It will take some planning for rolling out the package to stable but its available in his repo right now.

http://www.corsac.net/?rub=blog&post=1583

Did you remove the X-Debbugs-CC's? I worry that no one up to package it got actually informed by the RFP. Maybe not super important, since the RFP may not necessarily speed up things.

No. Should I resend them with these heading removed?

HulaHoop (HulaHoop):

Should I resend them with these heading removed?

No. Resend would result in duplicate report.

Removing the header results in adding fewer people to cc. Perhaps it was
my mistake to think multiple of these cc headers are allowed.

Do you think paxrat will require a .d config file folder? Would we need a custom paxrat.conf?

Do you think paxrat will require a .d config file folder?

Currently no although I think its planned but its optional thanks to Derlaft's commit. # style comments are suppoted in the main conf file:

https://github.com/derlaft/paxrat/commit/865273c1feb871d89adbbcb266779c836ee6b186

Would we need a custom paxrat.conf?

Probably. The conf should cover as many packages as possible to be useful to Debian users. Subgraph will be just focusing on a very limited selection of software because they are adding their own curated repo by default AFAIK.

Actually,

Do you think paxrat will require a .d config file folder? Would we need a custom paxrat.conf?

was the same question. Just in other words.

If we do need a custom paxrat.conf, then we also need a .d config folder. Otherwise we would have to use config-package-dev displace. Which is not pretty. Should be avoided if upstream is open to .d config folder.

Good question. I asked upstream because it depends on what direction they'll take:

https://github.com/subgraph/paxrat/issues/7

https://github.com/subgraph/paxrat/issues/1#issuecomment-172149998

Can you shed light on paxctld vs paxrat?

My last comment is wrong. David's description is on point.

I think their main reason for paxrat wouldn't apply to Whonix as its not a live environment.

Flags can be maintained paxctld's .conf file

All we need is a dpkg hook and a conf file for paxctld (the latter mirrors the Arch Linux one)

/etc/apt/apt.conf.d/70paxctld

DPkg::Post-Invoke { "/sbin/paxctld -c /etc/paxctld.conf";}

Or it can be run as daemon. Should there be a systemd service file for paxctld?

To land a grsec kernel ASAP we can use corsac's Jessie repo.

I will translate the list here into a format understood by paxctld:
https://github.com/thestinger/paxd/blob/master/paxd.conf

https://github.com/coldhakca/coldkernel/blob/master/paxctld.conf
https://github.com/tweksteen/paxctld/blob/master/paxctld.conf

To land a grsec kernel ASAP we can use corsac's Jessie repo.

To obtain a binary package or source package to compile?

To land a grsec kernel ASAP we can use corsac's Jessie repo.

Can we? Or will this result in the many issues I experience when I compiled a grsecurity kernel inside VirtualBox? Namely, X no longer starting, conflicts with AppArmor that were not there before and other obscure error messages?

At very least I want this kernel capable to run inside Qubes also.

Or it can be run as daemon. Should there be a systemd service file for paxctld?

You tell me. What would the daemon by doing?

In systemd terms, what would be the ExecStart= line?

Does arch linux's package require a systemd unit? And if not, why would we need one? And if it has one, can re-use it?

To obtain a binary package or source package to compile?

Both are possible because he supports Debian Stable dependencies in his repo but my priority is for a binary package installed by default. More details to follow.

Can we? Or will this result in the many issues I experience when I compiled a grsecurity kernel inside VirtualBox? Namely, X no longer starting, conflicts with AppArmor that were not there before and other obscure error messages?

There shouldn't be any probems with Apparmor. Exceptions for X and other software is what paxctld is for. The settings probably do conflict with Xen and Virtualbox and may need the custom built source package with the appropriate hypervisor compatibility setting enabled:

https://wiki.archlinux.org/index.php/Grsecurity#Compatibility

I'm not sure so testing on these platforms may be needed.

If that is the situation, then some service can boot the hardened kernel based on virt-what output.

You tell me. What would the daemon by doing?

All examples I saw have paxctld running as a service with no dpkg hooks. Their service files should be reusable.

Package roadmap:

• paxctld-conf
  • contains rules from paxd reformatted for compatibility at /etc/paxctld.conf
  • contains service file

• grsec-conf
  • contains a grsec customized settings conf to make it suitable for desktops by enabling system usb support and some other recommended settings by Yves at /etc/sysctl.d/grsec.conf

• anon-shared-build-apt-sources-corsac
  • /etc/apt/sources.list.d/corsac.list
  • can imitate chroot scripts provided with anon-shared-build-apt-sources-tpo but Yves is a Debian developer and his keys are already in the system keyring?

EDIT:

It makes sense to merge the first two packages together because they rely on each other to give a usable desktop experience.

Yes. Merge the first two packages.

I am trying to get rid of the third package also. Why are we back to using corsac's repository? Why not use Debian sid repository and apt pinning instead?

/etc/sysctl.d/grsec.conf -> needs a digitdigit- notation. For example 30-grsec.conf or so. Trying to foresee Debian shipping that name which would then conflict with our package.

If we ship an apt pinning file, we should also have it start with a digit, following by an underscore and ending with the .conf extension. For example 30_grsec.conf. I think the days of processing files in .d folders are counted because of Debian internal extensions .dpkg-old and temporary or backup files by editors such as file-name~.

If that is the situation, then some service can boot the hardened kernel based on virt-what output.

So it would only work with KVM and for all others it would use the non-grsec kernel?

If that is the situation, then some service can boot the hardened kernel based on virt-what output.

This is super difficult. virt-what is a userspace tool that requires an already running kernel. At the stage you would need to this detection, there is only grub. And doing such magic at the boot loader stage is very difficult. Another way would be to boot into a temporary kernel/system that runs the detection and then the required kernel using kexec, but this is also very difficult.

https://wiki.archlinux.org/index.php/Grsecurity#Compatibility indicates, that the binary kernel *might* not work depending on Debian's config. Quote:

Xen and virtualbox are not supported (conflicts with CONFIG_PAX_KERNEXEC and CONFIG_PAX_MEMORY_UDEREF)

What's Debian's config?

Yves is a Debian developer and his keys are already in the system keyring?

Probably included in the debian-keyring package, which ships a huge aggregated public key file. With the appropriate gpg command that single key could be extracted from there and then copied to /etc/apt/trusted.gpg.d/corsac.gpg. I don't remember off hand but could certainly figure out this again. However, as said above I hope this route can be avoided by using Debian sid instead.

Yes. Merge the first two packages.

OK

Why are we back to using corsac's repository? Why not use Debian sid repository and apt pinning instead?

We can but for source builds it won't be possible to do on stable because dependencies. (for now)

/etc/sysctl.d/grsec.conf -> needs a digitdigit- notation. For example 30-grsec.conf or so. Trying to foresee Debian shipping that name which would then conflict with our package.

I foresaw this and followed the number scheme used by Arch: 05-grsecurity.conf

So it would only work with KVM and for all others it would use the non-grsec kernel?

Likely and it would need testing to determine.

This is super difficult.

Another option would be to have the grsec kernel package installed but not set as the default in grub. On first run a script would run

$ grep menuentry /boot/grub/grub.cfg | cut -d "'" -f2 | grep "grsec$"

Now edit /etc/default/grub and change the GRUB_DEFAULT= line be to "Advanced options for Debian GNU\/Linux> followed by the kernel version string. Put the whole things in quotes, like this: GRUB_DEFAULT="Advanced options for Debian GNU\/Linux>Debian GNU/Linux, with Linux 4.3.3-grsec"

based on a user's choice from the first run wizard to enable default boot from a hardended kernel.

Debian GNU/Linux, with Linux 4.3.3-grsec

https://micahflee.com/2016/01/debian-grsecurity/

What's Debian's config?

I'll check.

I don't remember off hand but could certainly figure out this again. However, as said above I hope this route can be avoided by using Debian sid instead.

Up to you it depends on what want to do with source builds.

Why are we back to using corsac's repository? Why not use Debian sid repository and apt pinning instead?

We can but for source builds it won't be possible to do on stable because dependencies. (for now)

And how does corsac's repository help with that compared to Debian sid repository?

Framed this question another way: What's better/worse/different with corsac's repository vs Debian sid repository?

We can but for source builds it won't be possible to do on stable because dependencies. (for now)

Cannot work around that by downloading them from testing or sid? Or building inside a debootstrap sid chroot?

I don't think we should install a grsecurity kernel by default for the first iteration. That change is too complex. Apt pinning what what not. At first it would be good to have lots of users test this so we can iron out any issues. Specifically not breaking Whonix for most users.

Up to you it depends on what want to do with source builds.

I think they really matter. Since you can get some security improvements only when you compile from source, and since this is for increased security, and for advanced users, there will always be demand for it. The binary downloaded kernel would not be the full solution.

Now edit /etc/default/grub

Can be avoided by using /etc/default/grub.d or /etc/grub.d? (They both work. Have a different purpose.)

So it would only work with KVM and for all others it would use the non-grsec kernel?

Likely [...]

This is unacceptable as final solution. In the solution must potentially be room to make other platforms, Qubes [and VirtualBox] work also.

Anyhow. I think we reached consensus on the combined grsec-conf package already. (Combination of grsec-conf and paxctld-conf.) There should be no blocker anymore that prevents you working on this?

I'm almost done with the exceptions list. I merged some rules to cover Tor Browser and a few other binaries that weren't included. Changed some binary paths to reflect those on Debian...

I will link to it shortly.

With the sheer number of exceptions I'm questioning if we should just make pax softmode = 1 in grsec conf to make PaX protections opt-in. Hardly anything is covered anyhow: java, python, all gtk,qt, kde binaries web browsers and email clients are exempted.

Yes. Let's go simple for start and then see where we get.

And how does corsac's repository help with that compared to Debian sid repository?

The idea was you can just use the stable version of gcc to compile without needing the versions in sid.

Cannot work around that by downloading them from testing or sid? Or building inside a debootstrap sid chroot?

Interesting. I don't see why it shouldn't work.

I don't think we should install a grsecurity kernel by default for the first iteration. That change is too complex. Apt pinning what what not. At first it would be good to have lots of users test this so we can iron out any issues. Specifically not breaking Whonix for most users.

Of course. Then it would be available in developer's only?

I think they really matter. Since you can get some security improvements only when you compile from source, and since this is for increased security, and for advanced users, there will always be demand for it. The binary downloaded kernel would not be the full solution.

Agreed. We can have our cake and eat it too with the upstreaming progress thats happened.

Can be avoided by using /etc/default/grub.d or /etc/grub.d? (They both work. Have a different purpose.)

OK.

This is unacceptable as final solution. In the solution must potentially be room to make other platforms, Qubes [and VirtualBox] work also.

Some compatibility work for grsec to work inside Xen has happened though I can't remember where I saw it. It should work but because of Xen's design you can't have full grsec protection. Needs testing nothing is certain yet.

Anyhow. I think we reached consensus on the combined grsec-conf package already. (Combination of grsec-conf and paxctld-conf.) There should be no blocker anymore that prevents you working on this?

No blockers. I am done.

https://github.com/HulaHoopWhonix/grsec-desktop-conf

Some notes: When copying paxctld all my tabbing disappeared and the file looks hideous.

changelog.upstream will give problems until its fixed up. I'll try.

This can very well go to the testers and also the stable repository just
as any package. As long as it's not installed by default there really is
no reason a against it since it requires a manual action to install that
won't be happening accidentally without reading documentation.

• 05-grsecurity.conf needs a license header.

• paxctld.conf license?

• You need debian/rules using dh-systemd. See some Whonix package that ships a systemd service as example.

• /etc/paxctld.conf will be owned by another package? So we cannot overwrite it just like this. dpkg would complain about a conflict and abort installing either package. In this case, and in the absence of a '.d' folder, we would have to use config-package-dev. How to do this or finding a git commit to emulate would take me longer than actually doing it. So when you are ready to not make some changes to that file for a few hours and ask me to do it, I will do it quickly.

• run 'make deb-uachl-bumpup' to generate changelog.upstream and to add a second entry to the changelog (lintian would otherwise throw a warning that does not apply to us initial release does not close ITP bug)

• make sure you have lintian installed (sudo apt-get install lintian) and make sure it runs during 'make deb-pkg', or just run 'make deb-pkg' and then run lintian manually ('lintian'). Or better, the the right env variable to make lintian fail closed during genmkfile run.

make_use_lintian=true make deb-pkg

• And after we fixed all of that, try to actually install the package (make_use_lintian=true make deb-icup) and see if it's actually working.

needs a license header.

Its all gplv3. Do you have an example?

debian/rules using dh-systemd.

Please point to a package I can emulate.

/etc/paxctld.conf will be owned by another package?

I don't know. I opened a bu upstream to ask and see if some of my configs can be upstreamed.

What do you think about?

With the sheer number of exceptions I'm questioning if we should just make pax softmode = 1 in grsec conf to make PaX protections opt-in. Hardly anything is covered anyhow: java, python, all gtk,qt, kde binaries web browsers and email clients are exempted.

HulaHoop (HulaHoop):

> needs a license header.

Its all gplv3. Do you have an example?

These marked two lines:

https://github.com/Whonix/sdwdate/blob/50fd9eb567da5128c53d0592ee99a75334c6efa9/lib/systemd/system/sdwdate.service#L2-L3

> debian/rules using dh-systemd.

Please point to a package I can emulate.

sdwdate, control-port-filter-python, whonixcheck

> /etc/paxctld.conf will be owned by another package?

I don't know. I opened a bu upstream to ask and see if some of my configs can be upstreamed.

What do you think about?

Upstreaming is great so at some point we would not have to ship a
/etc/paxctld.conf file at all anymore. But in meanwhile if you want to
ship a /etc/paxctld.conf file which is owned by another package, then we
need config-package-dev to do the trick.

OK did the changes but need to test package.

Does this look good now?

https://github.com/HulaHoopWhonix/grsec-desktop-conf/blob/master/lib/systemd/system/paxctld.service

EDIT:

Link to upstream bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811451

debian/rules debian/control misses systemd entries.

I tried manually testing the 05-grsec.conf settings with no success. Editing the original grsec.conf doesn't work too. (I tried with the kernel conf lock setting disabled). I don't know what to try now...

What does not work? The package build/install or the grsecurity kernel
itself?

If you did not reboot you need to run 'sysctl -p' to make sysctl.d
changes take effect. Not sure it's useful to add to postinst since
reboot will be required anyhow?

You want softmode, right? So why use 'kernel.pax.softmode=0' instead of
'kernel.pax.softmode=1'?

What does not work? The package build/install or the grsecurity kernel itself?

The grsec kernel with these settings. It doesn't matter if its 05-grsecurity.conf or the default grsec.conf are changed, the settings don't apply and so the desktop cannot boot. I restarted the system each time and i tested with sysctl restrictions turned off (a security feature that was enabled to stop code from modifying a running kernel).

You want softmode, right? So why use 'kernel.pax.softmode=0' instead of 'kernel.pax.softmode=1'?

Yes I know it was set to 1.

The problem is the Debian kernel is not compiled with any virtualization support.

I could ask for it but it won't solve this for the other two hypervisors you want to support - unless they are custom builds which defeats the whole purpose of a binary package.

Could support for all hypervisors be enabled at the same time?

Could support for all hypervisors be enabled at the same time?

No because different feature tradeoffs are made depending on the hypervisor.

What about separate binary packages per hypervisor?

Not gonna happen. It took this long to package grsec for Debian because of their no duplicate packages policy so the patch had to be adjusted to work with the Debian flavor of the linux kernel.

The odds of them maintain different binary packages for this feature are nil.

I haven't been successful in getting upstream to understand that enabling this option is simple. Related: They opted to disable Grsecurity's MAC, RBAC because its "duplicate" functionality to Apparmor even though they don't conflict...

There is no "no duplicate package" policy in that sense. There is a "no
duplicate source code" policy. [Compare: linux-image-686 vs
linux-image-686 are not considered duplicates either. Sharing the very
same source package.] Therefore linux-grsec-generic, linux-grsec-xen,
etc. should not be a policy issue.

Coldkernel is a project that is better at what grsecurity-installer was meant to be:

https://github.com/coldhakca/coldkernel

Advantages:

• Actively maintained and updated
• Paxctld conf included
• Virtualization suport for multiple hypervisors
• Downloads over Tor (planned)

HulaHoop (HulaHoop):

https://github.com/coldhakca/coldkernel

Having had a glimpse at the code, it is still missing tons of required
features. Almost everything listed in T301. Anyhow. Good to know.

The author (Collin Childs) is associated with Tor

https://twitter.com/Phoul

Opened feature request:

linux-grsec-base: Multiple Compiled Grsec Kernels for Virtualization Compatibility

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816309

In T203#8183, @HulaHoop wrote:

Opened feature request:

linux-grsec-base: Multiple Compiled Grsec Kernels for Virtualization Compatibility

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816309

Awesome! Looks like it was recognized as valid.

Unfortunately the maintainer said that its a big maintenance burden for him but is open to outside help. I asked for this functionality to be added as optional for the source package.