Commit graph

8 commits

Author SHA1 Message Date
Ricardo M. Correia
f0cf8f4140 grsecurity: Fix module evaluation 2014-05-22 20:17:34 +02:00
Austin Seipp
67c309fe75 Fix fallout from 4f27ad14
Signed-off-by: Austin Seipp <aseipp@pobox.com>
2014-05-18 07:38:13 -05:00
Austin Seipp
4f27ad14a1 grsec: refactor grsecurity packages
This now provides a handful of different grsecurity kernels for slightly
different 'flavors' of packages. This doesn't change the grsecurity
module to use them just yet, however.

Signed-off-by: Austin Seipp <aseipp@pobox.com>
2014-05-17 14:09:43 -05:00
Austin Seipp
92abc4c610 kernel: enable AppArmor by default
AppArmor only requires a few patches to the 3.2 and 3.4 kernels in order
to work properly (with the minor catch grsecurity -stable includes the
3.2 patches.) This adds them to the kernel builds by default, removes
features.apparmor (since it's always true) and makes it the default MAC
system.

Signed-off-by: Austin Seipp <aseipp@pobox.com>
2014-05-17 14:09:09 -05:00
Ricardo M. Correia
5d5ca7b260 grsecurity: Update all patches
stable:  3.0-3.2.57-201404131252            -> 3.0-3.2.57-201404182109
test:    3.0-3.13.10-201404141717           -> 3.0-3.14.1-201404201132
vserver: 3.0-3.2.57-vs2.3.2.16-201404131253 -> 3.0-3.2.57-vs2.3.2.16-201404182110
2014-04-21 18:46:41 +02:00
Eelco Dolstra
29027fd1e1 Rewrite ‘with pkgs.lib’ -> ‘with lib’
Using pkgs.lib on the spine of module evaluation is problematic
because the pkgs argument depends on the result of module
evaluation. To prevent an infinite recursion, pkgs and some of the
modules are evaluated twice, which is inefficient. Using ‘with lib’
prevents this problem.
2014-04-14 16:26:48 +02:00
Austin Seipp
64efd184ed grsecurity: Fix GRKERNSEC_PROC restrictions
Previously we were setting GRKERNSEC_PROC_USER y, which was a little bit
too strict. It doesn't allow a special group (e.g. the grsecurity group
users) to access /proc information - this requires
GRKERNSEC_PROC_USERGROUP y, and the two are mutually exclusive.

This was also not in line with the default automatic grsecurity
configuration - it actually defaults to USERGROUP (although it has a
default GID of 1001 instead of ours), not USER.

This introduces a new option restrictProcWithGroup - enabled by default
- which turns on GRKERNSEC_PROC_USERGROUP instead. It also turns off
restrictProc by default and makes sure both cannot be enabled.

Signed-off-by: Austin Seipp <aseipp@pobox.com>
2014-04-12 11:16:05 -05:00
Austin Seipp
172dc1336f nixos: add grsecurity module (#1875)
This module implements a significant refactoring in grsecurity
configuration for NixOS, making it far more usable by default and much
easier to configure.

 - New security.grsecurity NixOS attributes.
   - All grsec kernels supported
   - Allows default 'auto' grsec configuration, or custom config
   - Supports custom kernel options through kernelExtraConfig
   - Defaults to high-security - user must choose kernel, server/desktop
     mode, and any virtualisation software. That's all.
   - kptr_restrict is fixed under grsecurity (it's unwriteable)
 - grsecurity patch creation is now significantly abstracted
   - only need revision, version, and SHA1
   - kernel version requirements are asserted for sanity
   - built kernels can have the uname specify the exact grsec version
     for development or bug reports. Off by default (requires
     `security.grsecurity.config.verboseVersion = true;`)
 - grsecurity sysctl support
   - By default, disabled.
   - For people who enable it, NixOS deploys a 'grsec-lock' systemd
     service which runs at startup. You are expected to configure sysctl
     through NixOS like you regularly would, which will occur before the
     service is started. As a result, changing sysctl settings requires
     a reboot.
 - New default group: 'grsecurity'
   - Root is a member by default
   - GRKERNSEC_PROC_GID is implicitly set to the 'grsecurity' GID,
     making it possible to easily add users to this group for /proc
     access
 - AppArmor is now automatically enabled where it wasn't before, despite
   implying features.apparmor = true

The most trivial example of enabling grsecurity in your kernel is by
specifying:

    security.grsecurity.enable          = true;
    security.grsecurity.testing         = true;      # testing 3.13 kernel
    security.grsecurity.config.system   = "desktop"; # or "server"

This specifies absolutely no virtualisation support. In general, you
probably at least want KVM host support, which is a little more work.
So:

    security.grsecurity.enable = true;
    security.grsecurity.stable = true; # enable stable 3.2 kernel
    security.grsecurity.config = {
      system   = "server";
      priority = "security";
      virtualisationConfig   = "host";
      virtualisationSoftware = "kvm";
      hardwareVirtualisation = true;
    }

This module has primarily been tested on Hetzner EX40 & VQ7 servers
using NixOps.

Signed-off-by: Austin Seipp <aseipp@pobox.com>
2014-04-11 22:43:51 -05:00