freedomofpress / ansible-role-grsecurity Goto Github PK

The test patches for Grsecurity have been discontinued: https://grsecurity.net/passing_the_baton.php The only options now are stable and stable2. Update the url-fetching module to omit the test patch type.

When using changed_when: in combination with command: gpg --recv-key ... you are only considering a change to have happened when the key is imported for the first time. This ignores the creation and revocation of subkeys or the key itself, new signatures, etc.. A more comprehensive changed_when will probably require a bit of tinkering to figure out, but will make for a more polished playbook. Nice too would be to print this info out during execution, perhaps using the debug module.

Since we are applying the ubuntu overlay we should also test and use their customized kernel config as the base for applying the grsec patch.

• Specify the airgap host OS
• Download and extract the current ubuntu specific kernel config
• Transfer the config to the airgap
• Verify the signature of the config file
• place the config file as .config in the directory where menuconfig is ran prior to patching the kernel with grsec.

In the context of SecureDrop, we prohibit hosting on cloud servers, due to the insecurity of allowing third-parties access to the virtualized environment. In the context of general web infrastructure, however, running a grsecurity-hardened kernel on cloud instances has a lot of benefits. We should consider supporting:

• aws
• digitalocean
• gandi
• linode

It will be simplest and safest to provide a base config for each provider, with the relevant grsecurity options enabled via make menuconfig. Therefore the logic surrounding grsecurity_build_strategy should be simplified, allowing admins to target a provider and build accordingly. The strategy should default to manual, requiring an admin to run make menuconfig themselves to ensure a stable build. At the role or playbook level, the build strategy can be overridden to target certain platforms.

The build strategy should be embedded in the filename, as well, to avoid confusion when building for disparate hosts.

The role logic currently assumes that one has access via HTTPS basic auth to the grsecurity download URLs. This made sense when the patches were freely available, but they have since been locked away behind auth. Therefore the role should support building from an on-disk patch file that the user provides separately (or backed up from a previous fetch).

Related discussion: freedomofpress/securedrop#2033

This git repository contains three separate roles:

• build-grsec-kernel
• build-grsec-metapackage
• install-grsec-kernel

The primary use of this repository is to publish the kernel maintenance documentation for use with SecureDrop. Some of the roles and associated playbooks are specifically intended for use with SecureDrop, e.g. build-grsec-metapackage, but the others are more generalized.

Most of the Ansible logic required to maintain SecureDrop exists in the SecureDrop repository—except the kernel build information. If we split up these roles, we can selectively include them in the SecureDrop repository, which should make the documentation story more straightforward for future (and current) maintainers.

We should check the target OS and warn or fail if conditions aren't met in the build and install roles. Right now the build role checks for "Debian" or "Ubuntu", but #30 shows that we need to be more fine-grained in what's considered an OK build host. At the very least, we should bail out with an informative message if Ubuntu 14.04 is detected on the target build host.

Haven't tested building on Debian 7, but Debian 8 64-bit works quite well.

Defined groups are needed for three grsecurity features that we haven't explored fully: /proc restriction, TPE (trusted path execution), and socket restrictions.

The default special groups are as follows and are used regardless of whether they exist yet:

• (1001) GID exempted from /proc restrictions
• (1005) GID for TPE-untrusted users
• (1006) GID for users with kernel-enforced SymlinksIfOwnerMatch

Debian does the following:

    addgroup --gid 64040 --system --quiet grsec-tpe ||true
    addgroup --gid 64041 --system --quiet grsec-sock-all ||true
    addgroup --gid 64042 --system --quiet grsec-sock-clt ||true
    addgroup --gid 64043 --system --quiet grsec-sock-srv ||true
    addgroup --gid 64044 --system --quiet grsec-proc ||true

Coldkernel does this:

sudo groupadd -g 9001 grsecproc
sudo groupadd -g 9002 tpeuntrusted
sudo groupadd -g 9003 denysockets

Eventually further down the line when we start leveraging such features more we need to handle creating these special groups. In particular it's an unintended (though unimportant) security hole that GID 1001 is currently exempted from /proc restriction (which is enabled in the default automatic configuration). Ideally it should be set to something else that won't match a user.

The current install role cautiously refuses to install a grsec deb package if the grsec kernel is already running. This limitation exists because the check for whether grsec is currently running isn't smart enough to check for a specific version that matches the deb file used.

We can add logic to extract the version from the deb file specified in grsecurity_deb_package, then verify that the same version is running post-reboot, via ansible_kernel.

We also need to test the upgrade procedure between multiple grsec versions. In particular, pay attention to the match filter used in the grub_menu_options module (see #22). Current theory: the way it's written it'll match the last entry, with entries sorted by order of appearance inside the GRUB config file. We want to make sure that the entries are sorted via semver, and the latest wins.

This repo serves a dual purpose:

1. Provide transparency around the SecureDrop kernel maintenance procedures,
2. Make grsecurity-patched kernels more generally accessible in non-SD contexts.

Therefore rather than shoehorning SD-related config changes into the grsec-build VM, let's create a separate VM specifically for building SD kernels (which expect the stable grsec patches and require subscription credentials) and point at a separate playbook.

I started using the Github wiki for this project to iterate on the build instructions. It was an experiment. Ultimately I was not very impressed with Github Wiki and don't see much benefit in continuing to use it. However, some improvements were made in the build instructions on the Wiki which should be merged back into build.md in the grsec repo.

The build-grsec-kernel role currently uses make-kpkg, provided by the package kernel-package in Debian-based systems, to build the kernel. I have come to believe this package may be unnecessary, and it has some downsides that are annoying to work around.

I discovered the issues with this package while trying to build a grsec testing kernel in Vagrant. My process: vagrant up && vagrant ssh, make menuconfig to turn on grsec (automatic configuration for server with security priority), build it with the make-kpkg command from compile.yml. This lead to an error (which annoyingly occurred after all the compilation and linking was done, so I had to wait about 1.5 hours before I saw it):

/usr/bin/make  INSTALL_MOD_PATH=/usr/local/src/linux-4.2.6/debian/linux-image-4.2.6-grsec        \
        INSTALL_FW_PATH=/usr/local/src/linux-4.2.6/debian/linux-image-4.2.6-grsec/lib/firmware/4.2.6-grsec  \
        INSTALL_PATH=/usr/local/src/linux-4.2.6/debian/linux-image-4.2.6-grsec//boot  install
make[2]: Entering directory `/usr/local/src/linux-4.2.6'
scripts/kconfig/conf  --silentoldconfig Kconfig
make[2]: Leaving directory `/usr/local/src/linux-4.2.6'
make[2]: Entering directory `/usr/local/src/linux-4.2.6'
sh ./arch/x86/boot/install.sh 4.2.6-grsec arch/x86/boot/bzImage \
        System.map "/usr/local/src/linux-4.2.6/debian/linux-image-4.2.6-grsec//boot"
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.2.6-grsec /usr/local/src/linux-4.2.6/debian/linux-image-4.2.6-grsec//boot/vmlinuz-4.2.6-grsec
/etc/kernel/postinst.d/apt-auto-removal: 84: /etc/kernel/postinst.d/apt-auto-removal: cannot create /etc/apt/apt.conf.d//01autoremove-kernels.dpkg-new: Permission denied
run-parts: /etc/kernel/postinst.d/apt-auto-removal exited with return code 2
make[3]: *** [install] Error 1
make[2]: *** [install] Error 2
make[2]: Leaving directory `/usr/local/src/linux-4.2.6'
make[1]: *** [debian/stamp/install/linux-image-4.2.6-grsec] Error 2
make[1]: Leaving directory `/usr/local/src/linux-4.2.6'
make: *** [kernel_image] Error 2

Some Googling lead me to a Launchpad issue, which explained that this was a bug in trusty's version of kernel-package (12.036+nmu3). The issue was triggered by an upstream kernel change, but that change only exposed the underlying bug in the Debian package (lmkl), which was fixed in 13.003.

The upshot is that you cannot build a Linux kernel with version >= 3.15-rc1 in Ubuntu trusty due to this bug in kernel-package. We didn't notice this bug earlier because we've been building stable grsecurity kernels (based on 3.14.x) for SecureDrop. I only noticed it when I tried to build a testing kernel (based on 4.2.x). In addition, Conor and Kevin have mostly been testing on DigitalOcean with Debian Jessie VM's, and Debian Jessie contains a sufficiently up-to-date version of kernel-package such that they hadn't encountered this problem before.

Ok, but I still want to be able to build a testing kernel in Vagrant. So what are my options?

1. Continue using the trusty base box, but pull in an updated version of kernel-package
2. Use a different base box (e.g. Ubuntu Precise or Debian Jessie), that provides an updated version of kernel-package.
3. Provide and support a custom base box for kernel building
4. Consider replacing the make-kpkg with the make deb-pkg target provided in the vanilla kernel sources.

When applying the grsecurity kernel patches to the vanilla Linux kernel for use on Ubuntu, it's necessary to pull in some config files from the Ubuntu overlay. When applying the patches for use on Debian, the overlay isn't necessary. The develop branch currently has some conditional logic to target different distros, which should be expanded. We should also provide separate Vagrant machines for Debian and Ubuntu to separate the build environments.

Ansible v2.0.2 introduces a breaking change in how ansible_ssh_user is handled. Prior to 2.0.2, it would automatically be populated with the username used for the SSH connection, but post 2.0.2 it's "null" by default, causing a number of tasks to error.

The pragma is now to use ansible_ssh_user|default(lookup('env', 'USER')), so we'll need to update the associated tasks in these roles to follow suit. Any changes should also work against Ansible v1.9, to make sure we have at least moderate backwards compatibility.

The logic managing privilege escalation was last updated in #50. It may be better to force become: no on the tasks that should be run without sudo privileges, and then the fail check at the beginning of the build role can be removed. Further testing required, naturally.

This is with ansible 1.9.2 so I might just need to upgrade. Posting this because I still want to run this playbook as one of many roles in a playbook.

I believe I have found an ansible related bug in a command in this playbook but I am unsure on how to debug deeper.

This does not impact the full playbook you provide.

I have been working on a fork to make a generic grsec role so as to to add it to pre-existing machines or vagrant dev machines.

What I have done so far: extracted the playbooks for "build-grsec-kernel" "build-grsec-metapackage" and "install-grsec-kernel" added the files build-grsecurity-kernel-test.yml/install-grsecurity-kernel.yml into the playbook root and changed the hosts: grsec-install to all.

In my playbook I have set the order of execution of the plays as:

- name: build grsec
  include: roles/grsec/build-grsecurity-kernel-test.yml
- name: install grsec
  include: roles/grsec/install-grsecurity-kernel.yml

Is there a better way to do this as this method causes me a lot of failures?

(unrelated bug I have not thus far been able to get to work correctly as a role and that is not the purpose of this issue).

The error message is:

TASK: [build-grsec-kernel | Extract Linux tarball (.tar -> directory).] ******* 
changed: [default] => {"changed": true, "check_results": {"cmd": "/bin/tar -C \"/usr/local/src\" --diff -f \"/usr/local/src/linux-4.4.4.tar\"", "err": "/bin/tar: linux-4.4.4: Warning: Cannot stat: No such file or directory\n/bin/tar: linux-4.4.4/.get_maintainer.ignore: Warning: Cannot stat: No such file or directory\n/bin/tar

this continues for every file in the linux-4.4.4 directory.

In order for me to solve this problem I modified the "xz --decompress" command and use "unxz" instead and that effectively bypassed the issue. In previous ansible playbooks I worked on I found that the command module for whatever reason has a tendency to mess up with alphanumeric characters (even while quoted).

With my change above I get the desired result:

TASK: [build-grsec-kernel | Extract Linux tarball (.xz -> .tar).] *************
changed: [default] => {"changed": true, "cmd": ["unxz", "/usr/local/src/linux-4.4.5.tar.xz"], "delta": "0:00:10.621326", "end": "2016-03-11 04:58:21.955393", "rc": 0, "start": "2016-03-11 04:58:11.334067", "stderr": "", "stdout": "", "warnings": []}

Additionally, the following play also fails in this setup: "Extract Linux tarball (.tar -> directory)".

With which manually changing to command tar gets past.

The last error which I'm now giving up on solving is:

TASK: [install-grsec-kernel | Install grsecurity-patched kernel deb package.] ***
failed: [default] => {"failed": true, "parsed": false}
BECOME-SUCCESS-zsmccdpktxieywucqbxaqcxjqrlrzfyb
Traceback (most recent call last):
File "/home/vagrant/.ansible/tmp/ansible-tmp-1457676639.85-211174664282747/apt", line 2246, in
main()
File "/home/vagrant/.ansible/tmp/ansible-tmp-1457676639.85-211174664282747/apt", line 602, in main
force=force_yes, dpkg_options=p['dpkg_options'])
File "/home/vagrant/.ansible/tmp/ansible-tmp-1457676639.85-211174664282747/apt", line 369, in install_deb
m.fail_json(msg="Error: %s\nSystem Error: %s" % (pkg._failure_string,str(e)))
UnboundLocalError: local variable 'pkg' referenced before assignment

and none of the grsec kernel deb files can be found.

From https://lkml.org/lkml/2016/9/11/28 (emphasis mine):

NOTE - the 3.14.y kernel series is now end-of-life. It will not be
receiving any more updates and should no longer be used at all.
Please use 4.4 if you want a LTS kernel that will last for another year,
or even better yet, just use the normal stable releases as those will
always contain the latest fixes and updates.

It seems like the only sensible thing to do is switch the next SD kernel to 4.4.32. There should be no problems with doing so, as Ubuntu Trusty is now on the 4.4 kernel series itself.

Hi,

My box sources for default debian and ubuntu builds does not find gcc-4.9 in either distro and I have to manually update the version numbers to 4.8 on each git pull. Could this be changed in the repo? It is unknown if this impacts nay other builds or not but I have not had a problem with this.

Thanks!

In #17, @garrettr said:

Since the grsecurity patches (for both stable and testing) change often, I'd prefer to avoid hardcoding things like the version of the grsecurity patch/link to the grsecurity path, and the SHA256 of the patch files. A few thoughts:

1. Can't we just get the latest patch from the corresponding RSS feed? (e.g. testing RSS, there's one for stable too but it needs auth). The XML looks extremely easy to parse: there's a single <channel> with one <item> (spender only ever has the latest patches up), and it has highly useful <title> and <link> attributes.
2. spender signs the patches. Can't we just verify the signature from his key instead of verifying SHA hashes (that have to be frequently updated)?

Yes, I'd very much prefer to ditch the SHA256 checksums in favor of the GPG verification—already removed them for the Linux tarballs, can easily do that for grsecurity as well.

Food for thought: we're fetching URLs and extracting checksum info over in the ossec repo—a more Pythonic implementation would be preferable, but the Ansible API is about to change soon:

Many API changes. Those integrating directly with Ansible's API will encounter breaking changes, but the new API is much easier to use and test.

If implementing as an ansible module, best to wait until 2.0 lands. Or we can use a separate tool, as in the case of the ossec repo.

The kernel_image package is generally sufficient on servers, but on desktops the kernel_headers package is quite useful. The build role must support creating that package (optionally), and the install role must support installing it (also optionally). Since the kernel_image deb package was built manually, the headers packages available in the distro's OS won't work, requiring manual compilation and installation.

The documentation in this repository serves two main purposes:

1. publicize kernel build procedure for grsec kernel used in SecureDrop instances
2. provide instructions for folks who want to compile grsec kernel for non-SecureDrop projects

Folks who want to use grsecurity for non-SecureDrop projects may find the grsecurity store useful. It's an officially maintained aspect of the grsecurity project that builds kernels on-demand.

With the addition of several Ansible roles for managing the build and install process for the grsecurity-patched kernel, we need to update the documentation to explain how the roles should be used. In particular, the grsecurity_patch_type and grsecurity_build_strategy vars should be explained in detail.

The step-by-step build docs currently in build.md can be folded into the docs to explain how to approach the grsecurity_build_strategy=manual use case, which is currently the default behavior of the build role.

• required vars (e.g. grsecurity_install_deb_package)
• default vars
• example playbooks
• further reading resources
  • linux kernel compilation
  • grsecurity/pax
• rename repo grsec -> ansible-role-grsecurity
• declare master the main branch (actually necessary due to confusion in #35 and #46)
• break up docs:
  • securedrop-specific docs into separate document
  • manual build steps in separate document

While testing a manual compile on a vivid64 virtualbox image (see #53 and #54) failed with:

scripts/selinux/genheaders/genheaders.c:129:18: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
    for (k = 0; k < max(1, 40 - strlen(map->name) - strlen(map->perms[j])); k++)
                  ^
  HOSTCC  scripts/selinux/mdp/mdp
  HOSTCC  scripts/kallsyms
  HOSTCC  scripts/conmakehash
  HOSTCC  scripts/sortextable
  HOSTCC  scripts/asn1_compiler
  HOSTCC  scripts/sign-file
scripts/sign-file.c:23:30: fatal error: openssl/opensslv.h: No such file or directory
 #include <openssl/opensslv.h>
                              ^
compilation terminated.
scripts/Makefile.host:126: recipe for target 'scripts/sign-file' failed
make[2]: *** [scripts/sign-file] Error 1
Makefile:547: recipe for target 'scripts' failed
make[1]: *** [scripts] Error 2
make[1]: Leaving directory '/home/vagrant/linux/linux-4.4.5'
debian/ruleset/targets/common.mk:295: recipe for target 'debian/stamp/build/kernel' failed
make: *** [debian/stamp/build/kernel] Error 2

This fixed it:

sudo aptitude install libssl-dev

Need to test more platforms to determine whether this is a vivid-specific issue. Tests and role validation tasks should identify supported platforms (#19, #33).

Different subscribers to grsecurity may have different URL routes, possibly including redirects. Update the URL lookup logic to support vars-based customization there.

See freedomofpress/securedrop#1245 for context. In summary: we need to ensure that the PaX flags are set correctly on grub binaries prior to running update-grub automatically after installing a new kernel image. Let's drop in a kernel postinst hook in the metapackage, which depends on the linux-image-grsec packages.

I created a script based on your instructions ( https://gist.github.com/anonymous/39b498911635c21ac61e ) and used it on an EC2 m3.2xlarge machine ( ami-df6a8b9b on http://cloud-images.ubuntu.com/releases/14.04/release-20150325/ ) but it doesn't boot upon final reboot.

This may be a noob question, but does your process work on cloud providers like EC2? Was it because I used an HVM instance instead of a PV instance? ( https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/virtualization_types.html )

The install-grsec-kernel role should eventually handle setting various sysctl parameters relevant to grsecurity, and then set the grsec_lock to 1.

The past few months have seen a lot of changes to this repo. During the rapid development period, we targeted develop for PRs, in the git-flow philosophy. The repo is starting to stabilize, so let's promote develop to master and target master with PRs henceforth.

There's a catch, though: back in August I merged some changes that messed up the repo commit history a bit (888384a). The solution here is a full rebase of develop on top of master, and then we can merge the new develop into master. I'll take care of that.

The install-grsec-kernel role should eventually handle configuration of persistent PaX flags for specified binaries via the paxctld daemon.

SecureDrop 0.3.10 includes a package securedrop-keyring for managing apt key rotations. The non-grsec packages:

• securedrop-app-code
• securedrop-ossec-agent
• securedrop-ossec-server

now declare securedrop-keyring as a dependency. Mostly this is a hack to allow unattended upgrades to seamlessly rotate the key, without requiring Admin intervention, but we should consider setting the same dependency for the securedrop-grsec metapackage, maintained in this repo.

Running repeated builds in a Vagrant VM is a drag. The Ansible role for building the kernel is smart enough to detect the number of VCPUs available, but by default in Vagrant this is 1—even on a host with 4 available. Figure that out and set accordingly. A sane default for RAM is probably 2GB, but I'd be open to making that dynamic according to the host, as well.

The grsecurity stable patches are now only available to project sponsors, and require basic authentication in order to access them. The experimental patches are still publicly available. The Ansible roles should default to using the experimental patches, with an option to target the stable patches.

Hey there,

I have been working on compiling a list of required pax flags needed to get applications to work post install, do you have a similar list that you could add to this role?

TASK [freedomofpress.grsecurity/roles/install-grsec-kernel : Reboot into the grsecurity kernel.] ***
Wednesday 18 January 2017  15:41:20 -0800 (0:00:00.408)       0:00:40.429 *****
ok: [fpf-common-box]

TASK [freedomofpress.grsecurity/roles/install-grsec-kernel : Wait for server to come back.] ***
Wednesday 18 January 2017  15:41:21 -0800 (0:00:01.177)       0:00:41.607 *****
skipping: [fpf-common-box]

TASK [freedomofpress.grsecurity/roles/install-grsec-kernel : Wait extra time for server to come back up.] ***
Wednesday 18 January 2017  15:41:21 -0800 (0:00:00.028)       0:00:41.635 *****
Pausing for 30 seconds
(ctrl+C then 'C' = continue early, ctrl+C then 'A' = abort)

ok: [fpf-common-box]

TASK [freedomofpress.grsecurity/roles/install-grsec-kernel : Refresh host facts.] ***
Wednesday 18 January 2017  15:41:51 -0800 (0:00:30.033)       0:01:11.668 *****
fatal: [fpf-common-box]: FAILED! => {"failed": true, "msg": "Timeout (32s) waiting for privilege escalation prompt: "}

There is no conditional on that wait_for task, so I suspect a syntax error that's being silently ignored.

The install role or a new, separate role might handle downloading and building gradm, the utility for managing the grsecurity RBAC (role-based access control) system, which allows further system hardening based upon grsecurity.

The package 'gradm2' in Debian, aside from being slightly outdated, does not work with our kernels because it's built to work with /dev/grsec2 instead of the proper /dev/grsec. I think it's meant to be used with the similarly outdated linux-patch-grsecurity2 package.

Packages that are required to build gradm: build-essential, bison and flex. Running make install places some important files in /etc/grsec. We might want to look at how Debian builds their gradm .deb package, update the sources and automate that process so we don't have to always require compilation / running make install.

Or we can talk to the maintainer and get them to fix the issues with gradm2. I've already reached out to them.

Relevant to fetch_linux_kernel_source.yml:

Assume an adversary has the capacity to MitM HTTPS. Then they can add a line in the format of a linux kernel checksum before the signature block within the clearsigned sha256sums.asc file and the signature will still verify as good. They could also serve us their position as a MitM to serve a backdoored kernel. Then, when we grep for the linux kernel checksum line, we use this unsigned, maliciously-inserted signature, which matches the backdoor kernel's checksum (an actual attack would have to be a little more nuanced, taking into account how we pipe to cut the options we use, but certainly seems possible). Bad news.

So, after reading through the GPG man page for the bajillionth time and searching the web extensively, I've found no way to resolve this problem with GPG parameters alone. I propose that we make some assertions about the file before verifying:

• The 1st line of the file is:

-----BEGIN PGP SIGNED MESSAGE-----

• The last line of the file is:

-----END PGP SIGNATURE-----

• Somewhere between the 2nd and last line of the file is the line:

-----BEGIN PGP SIGNATURE-----

• No lines other than the three lines above start with:

-----

Specifically, start incorporating the upstream grsec patch revisions into the kernel deb package and enhance ansible comparison detection when installing.

The revision is passed as part of the make-kpkg command, specifically the --revision flag. This part of the code needs to be expanded (as well as other hard-coded references and the detection/comparison logic):

fakeroot make-kpkg
  --revision 10.00.{{ grsecurity_build_strategy }}

Test if this tackles the issue of attempting to install the same upstream kernel version with a different revision without scary ncurses prompt warnings. If not, then shove that issue off to another ticket to investigate/resolve.

Was initially implemented via #73, but the output of lsb_release -a under Stretch and Sid have since changed, so we can convert the combined distro vars logic that expects stretch/sid into true distro vars.

I have a painstakingly curated .config with the grsec/pax options I want to use. As of now I can manually add a copy: to the install-grsec-kernel for it to be built automatically.

However I wonder if it be useful to seamlessly add it to the grsec playbook with a variable and automatic copy task, would this be possible?

Personally I find that unless someone really knows the precise kernel features that they know they need, leaving it to common users to figure out is an error prone process and that they would be better off with a strict kernel config file at first and only later open it up if needed for some feature they require.

This feature is probably only worthwhile for the install-grsec-kernel playbook.

If this seems reasonable, something else I thought of considerations is the inclusion of arrays of possible GRKERNSEC profiles such as listed on https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Usage_Type

some of which make a lot of sense for this playbook out of the box:

GRKERNSEC_CONFIG_SERVER=y
GRKERNSEC_CONFIG_VIRT_GUEST=y
GRKERNSEC_CONFIG_VIRT_VIRTUALBOX=y

which could be a single variable like:

{{ grkernsec_server_virt_guest_virtualbox}} (or something to that effect)

if users of this playbook intend to use it for servers or desktops ( {{ grkernsec_desktop}} ), they should be able to copy the playbook into a new directory and change the default profile definitions inside defaults/main.yml and be done with any required changes. Currently that is not possible because it requires manually updating the .config file on the system which is something we want users to avoid with orchestration.

Link.

heartsucker@archimedes:~/code/freedom-of-the-press/ansible-role-grsecurity (master)$ vagrant up grsec-build
Bringing machine 'grsec-build' up with 'virtualbox' provider...
==> grsec-build: Box 'ubuntu/vivid64' could not be found. Attempting to find and install...
    grsec-build: Box Provider: virtualbox
    grsec-build: Box Version: >= 0
The box 'ubuntu/vivid64' could not be found or
could not be accessed in the remote catalog. If this is a private
box on HashiCorp's Atlas, please verify you're logged in via
`vagrant login`. Also, please double-check the name. The expanded
URL and error message are shown below:

URL: ["https://atlas.hashicorp.com/ubuntu/vivid64"]
Error: The requested URL returned error: 404 Not Found

Brought up first in #85 (comment), we should investigate modifying our Vagrantfile to instruct QEMU to emulate the processors of recommended SD hardware (currently some Intel NUC model). One thing to consider is that this has the potential to slow down compilation, so maybe it's best we reserve this for use in the grsec-install machine (we should also consider using it for for app-prod and app-mon in SD). On that note, it would be good to investigate if Vagrant chooses the fastest reliable CPU option by default.

The kernel version numbers currently listed in build.md are out of date. Worse, the URLs provided for the grsecurity patch and sig result in 404s:

$ wget https://grsecurity.net/stable/grsecurity-3.0-3.14.21-201410131959.patch{,.sig}
--2015-05-27 10:24:06--  https://grsecurity.net/stable/grsecurity-3.0-3.14.21-201410131959.patch
Resolving grsecurity.net (grsecurity.net)... 50.251.85.49
Connecting to grsecurity.net (grsecurity.net)|50.251.85.49|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2015-05-27 10:24:08 ERROR 404: Not Found.

--2015-05-27 10:24:08--  https://grsecurity.net/stable/grsecurity-3.0-3.14.21-201410131959.patch.sig
Reusing existing connection to grsecurity.net:443.
HTTP request sent, awaiting response... 404 Not Found
2015-05-27 10:24:08 ERROR 404: Not Found.

Maintaining this information by hand is a bit of a pain, but keeping the hard-coded values up-to-date within a six-month window seems reasonable. Additionally, the docs should link out to the grsecurity download page so folks know where to go if the hard-coded URLs don't work.

A new version of grsecurity was released on 2015-05-22. This version should be tested on VMs and hardware prior to updating the docs here.

The current state of build-kernel-package role in develop is leveraging static config files shipped with the role. Let's shoot for generating .config files instead, rather than reusing config files across different hosts.

As @ageis pointed out, we should improve how the filename for the built package is handled, because it'll include the kernel version, and therefore can't be hard-coded.

Last year there was a regression in the version of kernel-package served out of the trusty repos that prevented builds of the test kernel sources (#30). The upstream version in trusty has since been patched, so we should be able to use trusty for builds again—test and confirm, and update the Vagrantfile if so, so builds happen under Trusty by default.

In the context of building grsecurity-patched kernels for SecureDrop, we want to build on Trusty for Trusty, since make-kpkg pulls in the config for the currently running kernel by default.

I would find it useful to include paxtest into this task:

- name: Install PaX utilities.
  apt:
    name: "{{ item }}"
    state: present
  with_items:
    - paxctl
    - paxtest

The main purpose of me wanting this is for post install testing. It may also be valuable to have a second list of tests in tests.yml for:

• a single run post install paxtest tests or reports.
• a recurring job for daily or weekly checking.
• signed kernel checks.

with notifications on any changes. Otherwise I will probably get around to adding these additional checks to my own playbook eventually and can offer a pull request when ready.

Migrated from freedomofpress/securedrop#851

The kernel build process should be performed as a normal user, without sudo. In Linux Kernel in a Nutshell, Kroah-Hartman is unequivocal about this:

Do not configure or build your kernel with superuser permissions enabled! [...] Everything in this book—downloading the kernel source code, uncompressing it, configuring the kernel, and building it—should be done as a normal user on the machine. Only the two or three commands it takes to install a new kernel should be done as the superuser (root).

We can detect via ansible_user_uid whether the role is being executed as root, and warn or fail if so. We should also update the documentation to discourage the use of sudo. The example playbooks already do not use sudo, with the exception of the build-grsec-metapackage role.

Furthermore, GKH recommends:

Do not do any kernel development under the /usr/src directory tree at all, but only in a local user directory where nothing bad can happen to the system.

Technically we're not using /usr/src—rather /usr/local/src—but we can and should update the role to build in the user's home directory, via ansible_user_dir, as recommended.

The fetch task for retrieving the build deb packages is inappropriately using with_fileglob, which references paths on the Ansible controller, so fetching will never work when building on a remote host:

As described in #109, we've broken out the logic maintained in this repo into separate, more narrowly focused repositories. Since #107 we have been maintaining documentation for rebuilding SecureDrop kernels from source in this repository. We should preserve that documentation, and furthermore convert this repository to be documentation-focused on the SD rebuild story.

We have multiple rebuild flows now, depending on 3.x versus 4.x images, so the documentation will need to grow, as well.

The manual build guide should be tested again with a full manual workflow. When FPF builds a new kernel for SD, the Ansible logic is used. Pending resolution of #101, the manual build docs should be fully up to date, and allow someone with both the kernel sources and the patch to reproduce the binary linux-image deb package.

Related discussion: freedomofpress/securedrop#2033