Commit Graph

24 Commits

Author SHA1 Message Date
Joachim Fasting
d6ff445f10
grsecurity: 4.8.15-201612301949 -> 4.8.16-201701062021 2017-01-07 08:01:41 +01:00
Joachim Fasting
f0e77cd07d
grsecurity: 4.8.14-201612110933 -> 4.8.15-201612151923 2016-12-16 12:46:44 +01:00
Joachim Fasting
601058e0e2
grsecurity: 4.8.13-201612082118 -> 4.8.14-201612110933 2016-12-11 19:09:16 +01:00
Joachim Fasting
d1a5dc0b1c
grsecurity: 4.8.12-201612062306 -> 4.8.13-201612082118 2016-12-09 15:31:02 +01:00
Joachim Fasting
9578299bbe
grsecurity: 4.8.11-201611271225 -> 4.8.12-201612031658 2016-12-06 01:24:32 +01:00
Joachim Fasting
b90ed0cc80
grsecurity: 4.8.10-201611232213 -> 4.8.11-201611271225 2016-11-28 11:41:10 +01:00
Joachim Fasting
96194467e6
grsecurity: 4.8.8-201611150756 -> 4.8.10-201611210813 2016-11-21 23:15:14 +01:00
Joachim Fasting
0d4e1b5edd
grsecurity: 4.8.7-201611142350 -> 4.8.8-201611150756 2016-11-15 22:57:25 +01:00
Joachim Fasting
cad9212813
grsecurity: 4.7.10-201611011946 -> 4.8.7-201611102210 2016-11-14 00:16:19 +01:00
Joachim Fasting
5440c1a64c
grsecurity: 4.7.9-201610200819 -> 4.7.10-201610222037
Notably, this pulls in the dirtycow fix from upstream (but I've been
unable to execute the POC exploits on grsec kernels without that fix
...)
2016-10-23 17:14:40 +02:00
Joachim Fasting
ed5d146e9d
grsecurity: 4.7.7-201610101902 -> 4.7.9-201610200819 2016-10-21 01:50:53 +02:00
Joachim Fasting
ce73a3ea0f grsecurity: 4.7.6-201609301918 -> 4.7.7-201610101902 2016-10-11 13:15:16 +02:00
Joachim Fasting
2ec9a1a955
grsecurity: 4.7.5-201609261522 -> 4.7.6-201609301918 2016-10-01 08:47:30 +02:00
Joachim Fasting
98a9d815e0
grsecurity: 4.7.4-201609211951 -> 4.7.5-201609261522 2016-09-27 01:43:50 +02:00
Joachim Fasting
d082a7c0fd
grsecurity: 4.7.3-201609072139 -> 4.7.4-201609152234 2016-09-16 11:18:42 +02:00
Joachim Fasting
91674b75d3
grsecurity: 4.7.2-201608312326 -> 4.7.3-201609072139 2016-09-10 17:06:42 +02:00
Joachim Fasting
cf592a8969
grsecurity: 4.7.1-201608161813 -> 4.7.2-201608211829 2016-08-23 01:49:34 +02:00
Joachim Fasting
ba20363f11
grsecurity: 4.7-201608151842 -> 4.7.1-201608161813 2016-08-17 15:19:27 +02:00
Joachim Fasting
d82ddd6dc0
grsecurity: 4.7-201608131240 -> 4.7-201608151842 2016-08-16 17:50:37 +02:00
Joachim Fasting
9062c67914
grsecurity: 4.6.5-201607312210 -> 4.7-201608131240 2016-08-15 20:36:46 +02:00
Joachim Fasting
83f783c00f
grsecurity: 4.6.4-201607242014 -> 4.6.5-201607272152 2016-07-29 00:24:00 +02:00
Joachim Fasting
416120e0c7
grsecurity: 4.6.3-201607070721 -> 4.6.4-201607112205 2016-07-12 15:15:09 +02:00
Joachim Fasting
a2ebf45b47
grsecurity: 4.5.7-201606302132 -> 4.6.3-201607070721 2016-07-07 19:34:58 +02:00
Joachim Fasting
75b9a7beac
grsecurity: implement a single NixOS kernel
This patch replaces the old grsecurity kernels with a single NixOS
specific grsecurity kernel.  This kernel is intended as a general
purpose kernel, tuned for casual desktop use.

Providing only a single kernel may seem like a regression compared to
offering a multitude of flavors.  It is impossible, however, to
effectively test and support that many options.  This is amplified by
the reality that very few seem to actually use grsecurity on NixOS,
meaning that bugs go unnoticed for long periods of time, simply because
those code paths end up never being exercised.  More generally, it is
hopeless to anticipate imagined needs.  It is better to start from a
solid foundation and possibly add more flavours on demand.

While the generic kernel is intended to cover a wide range of use cases,
it cannot cover everything.  For some, the configuration will be either
too restrictive or too lenient.  In those cases, the recommended
solution is to build a custom kernel --- this is *strongly* recommended
for security sensitive deployments.

Building a custom grsec kernel should be as simple as
```nix
linux_grsec_nixos.override {
  extraConfig = ''
    GRKERNSEC y
    PAX y
    # and so on ...
  '';
}
```

The generic kernel should be usable both as a KVM guest and host.  When
running as a host, the kernel assumes hardware virtualisation support.
Virtualisation systems other than KVM are *unsupported*: users of
non-KVM systems are better served by compiling a custom kernel.

Unlike previous Grsecurity kernels, this configuration disables `/proc`
restrictions in favor of `security.hideProcessInformation`.

Known incompatibilities:
- ZFS: can't load spl and zfs kernel modules; claims incompatibility
  with KERNEXEC method `or` and RAP; changing to `bts` does not fix the
  problem, which implies we'd have to disable RAP as well for ZFS to
  work
- `kexec()`: likely incompatible with KERNEXEC (unverified)
- Xen: likely incompatible with KERNEXEC and UDEREF (unverified)
- Virtualbox: likely incompatible with UDEREF (unverified)
2016-06-14 00:08:20 +02:00