alioth/nixpkgs
3
0
Fork 0
forked from mirrors/nixpkgs
Code Releases Activity
nixpkgs/pkgs/os-specific/linux/kernel/grsecurity-nixos-config.nix

64 lines
1.5 KiB
Nix
Raw Normal View History

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-13 23:04:56 +01:00
{ stdenv }:
with stdenv.lib;
''
grsecurity: revamp nixos kernel config Cleanup: - Restructure & add some commentary - Remove redundant option specs given the auto config constraints (some are left in for documentation purposes) Changes: - GRKERNSEC_CONFIG_VIRT_HOST -> GUEST The former deselects paravirtualization and friends - PAX_LATENT_ENTROPY n -> y (implied by auto) - GRKERNSEC_ACL_HIDEKERN y -> n Possibly useless with redistribution
2016-10-02 17:35:43 +01:00
# Auto configuration with these constraints will enable most of the
# important features (RAP, UDEREF, ASLR, memory sanitization).
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-13 23:04:56 +01:00
GRKERNSEC_CONFIG_AUTO y
GRKERNSEC_CONFIG_DESKTOP y
grsecurity: revamp nixos kernel config Cleanup: - Restructure & add some commentary - Remove redundant option specs given the auto config constraints (some are left in for documentation purposes) Changes: - GRKERNSEC_CONFIG_VIRT_HOST -> GUEST The former deselects paravirtualization and friends - PAX_LATENT_ENTROPY n -> y (implied by auto) - GRKERNSEC_ACL_HIDEKERN y -> n Possibly useless with redistribution
2016-10-02 17:35:43 +01:00
GRKERNSEC_CONFIG_PRIORITY_SECURITY y
# We specify virt guest rather than host here, the latter deselects e.g.,
# paravirtualization.
GRKERNSEC_CONFIG_VIRT_GUEST y
# Note: assumes platform supports CPU-level virtualization (so no pentium 4)
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-13 23:04:56 +01:00
GRKERNSEC_CONFIG_VIRT_EPT y
GRKERNSEC_CONFIG_VIRT_KVM y
grsecurity: revamp nixos kernel config Cleanup: - Restructure & add some commentary - Remove redundant option specs given the auto config constraints (some are left in for documentation purposes) Changes: - GRKERNSEC_CONFIG_VIRT_HOST -> GUEST The former deselects paravirtualization and friends - PAX_LATENT_ENTROPY n -> y (implied by auto) - GRKERNSEC_ACL_HIDEKERN y -> n Possibly useless with redistribution
2016-10-02 17:35:43 +01:00
# PaX control
grsecurity: support non-enforcing mode Until we've made sure that most things actually work out of the box, we need to give people a way of continuing to use the system without completely disabling grsecurity. Set sysctl kernel.pax.softmode=1 or boot with pax.softmode=1
2016-08-16 13:03:40 +01:00
PAX_SOFTMODE y
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-13 23:04:56 +01:00
PAX_PT_PAX_FLAGS y
grsecurity: enable support for setting pax flags via xattrs While useless for binaries within the Nix store, user xattrs are a convenient alternative for setting PaX flags to executables outside of the store. To use disable secure memory protections for a non-store file foo, do $ setfattr -n user.pax.flags -v em foo
2016-07-16 15:58:15 +01:00
PAX_XATTR_PAX_FLAGS y
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-13 23:04:56 +01:00
PAX_EI_PAX n
grsecurity: enable PAX_INITIFY Uses gcc plugin to detect more instances where memory used during init can be freed.
2016-12-09 11:08:21 +00:00
PAX_INITIFY y
grsecurity: revamp nixos kernel config Cleanup: - Restructure & add some commentary - Remove redundant option specs given the auto config constraints (some are left in for documentation purposes) Changes: - GRKERNSEC_CONFIG_VIRT_HOST -> GUEST The former deselects paravirtualization and friends - PAX_LATENT_ENTROPY n -> y (implied by auto) - GRKERNSEC_ACL_HIDEKERN y -> n Possibly useless with redistribution
2016-10-02 17:35:43 +01:00
# The bts instrumentation method is compatible with binary only modules.
#
# Note: if platform supports SMEP, we could do without this
PAX_KERNEXEC_PLUGIN_METHOD_BTS y
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-13 23:04:56 +01:00
grsecurity: revamp nixos kernel config Cleanup: - Restructure & add some commentary - Remove redundant option specs given the auto config constraints (some are left in for documentation purposes) Changes: - GRKERNSEC_CONFIG_VIRT_HOST -> GUEST The former deselects paravirtualization and friends - PAX_LATENT_ENTROPY n -> y (implied by auto) - GRKERNSEC_ACL_HIDEKERN y -> n Possibly useless with redistribution
2016-10-02 17:35:43 +01:00
# Additional grsec hardening not implied by auto constraints
GRKERNSEC_IO y
grsecurity: enable optional sysfs restrictions Fairly severe, but can be disabled at bootup via grsec_sysfs_restrict=0. For the NixOS module we ensure that it is disabled, for systemd compatibility.
2016-12-05 18:04:49 +00:00
GRKERNSEC_SYSFS_RESTRICT y
grsecurity: enable ability to lock in readonly mounts
2016-12-05 22:55:40 +00:00
GRKERNSEC_ROFS y
grsecurity: enable pax size overflow plugin
2016-08-16 13:05:17 +01:00
grsecurity: enable module hardening
2016-12-05 18:19:33 +00:00
GRKERNSEC_MODHARDEN y
grsecurity: revamp nixos kernel config Cleanup: - Restructure & add some commentary - Remove redundant option specs given the auto config constraints (some are left in for documentation purposes) Changes: - GRKERNSEC_CONFIG_VIRT_HOST -> GUEST The former deselects paravirtualization and friends - PAX_LATENT_ENTROPY n -> y (implied by auto) - GRKERNSEC_ACL_HIDEKERN y -> n Possibly useless with redistribution
2016-10-02 17:35:43 +01:00
# Disable protections rendered useless by redistribution
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-13 23:04:56 +01:00
GRKERNSEC_HIDESYM n
GRKERNSEC_RANDSTRUCT n
grsecurity: revamp nixos kernel config Cleanup: - Restructure & add some commentary - Remove redundant option specs given the auto config constraints (some are left in for documentation purposes) Changes: - GRKERNSEC_CONFIG_VIRT_HOST -> GUEST The former deselects paravirtualization and friends - PAX_LATENT_ENTROPY n -> y (implied by auto) - GRKERNSEC_ACL_HIDEKERN y -> n Possibly useless with redistribution
2016-10-02 17:35:43 +01:00
# Disable protections covered by vanilla mechanisms
GRKERNSEC_DMESG n
GRKERNSEC_KMEM n
GRKERNSEC_PROC n
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-13 23:04:56 +01:00
grsecurity: revamp nixos kernel config Cleanup: - Restructure & add some commentary - Remove redundant option specs given the auto config constraints (some are left in for documentation purposes) Changes: - GRKERNSEC_CONFIG_VIRT_HOST -> GUEST The former deselects paravirtualization and friends - PAX_LATENT_ENTROPY n -> y (implied by auto) - GRKERNSEC_ACL_HIDEKERN y -> n Possibly useless with redistribution
2016-10-02 17:35:43 +01:00
# Disable protections that are inappropriate for a general-purpose kernel
GRKERNSEC_NO_SIMULT_CONNECT n
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-13 23:04:56 +01:00
grsecurity: revamp nixos kernel config Cleanup: - Restructure & add some commentary - Remove redundant option specs given the auto config constraints (some are left in for documentation purposes) Changes: - GRKERNSEC_CONFIG_VIRT_HOST -> GUEST The former deselects paravirtualization and friends - PAX_LATENT_ENTROPY n -> y (implied by auto) - GRKERNSEC_ACL_HIDEKERN y -> n Possibly useless with redistribution
2016-10-02 17:35:43 +01:00
# Enable additional audititing
GRKERNSEC_AUDIT_MOUNT y
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-13 23:04:56 +01:00
GRKERNSEC_AUDIT_PTRACE y
GRKERNSEC_FORKFAIL y
grsecurity: revamp nixos kernel config Cleanup: - Restructure & add some commentary - Remove redundant option specs given the auto config constraints (some are left in for documentation purposes) Changes: - GRKERNSEC_CONFIG_VIRT_HOST -> GUEST The former deselects paravirtualization and friends - PAX_LATENT_ENTROPY n -> y (implied by auto) - GRKERNSEC_ACL_HIDEKERN y -> n Possibly useless with redistribution
2016-10-02 17:35:43 +01:00
# Wishlist: support trusted path execution
GRKERNSEC_TPE n
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-13 23:04:56 +01:00
GRKERNSEC_SYSCTL y
GRKERNSEC_SYSCTL_DISTRO y
grsecurity: delay toggling of sysctls until system is up We generally trust init, so there's little point in having these enabled during early bootup; it accomplishes little except fill our logs with spam.
2016-12-05 18:02:10 +00:00
# Assume that appropriate sysctls are toggled once the system is up
GRKERNSEC_SYSCTL_ON n
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-13 23:04:56 +01:00
''
Copy permalink