Upgrade kernels to mitigate Stack Clash

freedomofpress / ansible-role-grsecurity

The documentation and build system for the grsecurity kernel maintained by the Freedom of the Press Foundation for SecureDrop

GNU General Public License v2.0

49 stars 13 forks source link

Upgrade kernels to mitigate Stack Clash #100

Closed conorsch closed 7 years ago

conorsch commented 7 years ago

Implements the mitigations described in https://github.com/freedomofpress/securedrop/issues/1861. These changes are SecureDrop-specific, and in addition to updating the grsecurity kernel patch version, also provide a sysctl modification to vm.heap_stack_gap, raising it 64KB -> 1MB, as recommended by grsecurity. The sysctl options are rolled into the securedrop-grsec metapackage, same as the paxctl flags added via #91.

Also commits the latest kernel config used for SecureDrop, which is the default Ubuntu Trusty config with the grsecurity patch set applied with high security settings, as indicated in the docs, and thereby closes #3. We'll need to update that if and when we move to the 4.x kernel series.

msheiny commented 7 years ago

@conorsch - i really want to do a full test against this since its been a while since i ran this role -- im assuming this PR isnt urgent to get in since youve already built it but if my assumption is incorrect let me know

conorsch commented 7 years ago

@msheiny That's right, changes are already live and shipped. In order to test locally, I recommend something like:

vagrant up --no-provision grsec-build-securedrop
ansible-playbook -vv --diff -i .vagrant/provisioners/ansible/inventory/vagrant_ansible_inventory examples/build-grsecurity-kernel-securedrop.yml  --tags kernel

The manual playbook invocation is necessary for the prompt tasks to permit input from stdin, otherwise they'll be skipped and the role will fail.

msheiny commented 7 years ago

So two issues I ran into while deploying -- not really code specific but worth noting for the future:

When you try to deploy the same kernel version from deb package directly -- you'll get a big scary error about existing modules in place. The only way I found to get past this was to either backup/move the existing dir or set clobber_modules via /etc/kernel-img.conf. I added commit that allows one to do that via the second option.
When we deploy newer versions of kernels to over-write existing kernels with the same version... this is problematic because it makes it harder to check to see whats running during operations. Sure - I can check the dpkg version of whats installed but what if the system hasnt been rebooted yet and is still running an older version? I think we should always update kernel version that displays when you query from within the os. in other words, uname -r output should always be incrementing when we update kernels internally.

conorsch commented 7 years ago

@msheiny Revised GPG fingerprints to use longids, and moved the sysctl options to a vars-based template. Ready for re-review.