nixpkgs/nixos/modules/security/grsecurity.xml

<chapter xmlns="http://docbook.org/ns/docbook"
         xmlns:xlink="http://www.w3.org/1999/xlink"
         xmlns:xi="http://www.w3.org/2001/XInclude"
         version="5.0"
         xml:id="sec-grsecurity">

  <title>Grsecurity/PaX</title>

  <para>
    Grsecurity/PaX is a set of patches against the Linux kernel that
    implements an extensive suite of
    <link xlink:href="https://grsecurity.net/features.php">features</link>
    designed to increase the difficulty of exploiting kernel and
    application bugs.
  </para>

  <para>
    The NixOS grsecurity/PaX module is designed with casual users in mind and is
    intended to be compatible with normal desktop usage, without
    <emphasis>unnecessarily</emphasis> compromising security.  The
    following sections describe the configuration and administration of
    a grsecurity/PaX enabled NixOS system.  For more comprehensive
    coverage, please refer to the
    <link xlink:href="https://en.wikibooks.org/wiki/Grsecurity">grsecurity wikibook</link>
    and the
    <link xlink:href="https://wiki.archlinux.org/index.php/Grsecurity">Arch
    Linux wiki page on grsecurity</link>.

    <note><para>grsecurity/PaX is only available for the latest linux -stable
    kernel; patches against older kernels are available from upstream only for
    a fee.</para></note>
    <note><para>We standardise on a desktop oriented configuration primarily due
    to lack of resources.  The grsecurity/PaX configuration state space is huge
    and each configuration requires quite a bit of testing to ensure that the
    resulting packages work as advertised.  Defining additional package sets
    would likely result in a large number of functionally broken packages, to
    nobody's benefit.</para></note>
  </para>

  <sect1 xml:id="sec-grsec-enable"><title>Enabling grsecurity/PaX</title>

  <para>
    To make use of grsecurity/PaX on NixOS, add the following to your
    <filename>configuration.nix</filename>:
    <programlisting>
      security.grsecurity.enable = true;
    </programlisting>
    followed by
    <programlisting>
      # nixos-rebuild boot
      # reboot
    </programlisting>
    <note><para>
      Enabling the grsecurity module overrides
      <option>boot.kernelPackages</option>, to reduce the risk of
      misconfiguration.  <xref linkend="sec-grsec-custom-kernel" />
      describes how to use a custom kernel package set.
    </para></note>

    For most users, further configuration should be unnecessary.  All users
    are encouraged to look over <xref linkend="sec-grsec-security" /> before
    using the system, however.  If you experience problems, please refer to
    <xref linkend="sec-grsec-issues" />.
  </para>

  <para>
    Once booted into the new system, you can optionally use
    <command>paxtest</command> to exercise various PaX features:
    <screen><![CDATA[
    # nix-shell -p paxtest --command 'paxtest blackhat'
    Executable anonymous mapping             : Killed
    Executable bss                           : Killed
    # ... remaining output truncated for brevity
    ]]></screen>
  </para>

  </sect1>

  <sect1 xml:id="sec-grsec-declarative-tuning"><title>Declarative tuning</title>

  <para>
    The default configuration mode is strictly declarative.  Some features
    simply cannot be changed at all after boot, while others are locked once the
    system is up and running.  Moreover, changes to the configuration enter
    into effect only upon booting into the new system.
  </para>

  <para>
    The NixOS module exposes a limited number of options for tuning the behavior
    of grsecurity/PaX.  These are options thought to be of particular interest
    to most users.  For experts, further tuning is possible via
    <option>boot.kernelParams</option> (see
    <xref linkend="sec-grsec-kernel-params" />) and
    <option>boot.kernel.sysctl."kernel.grsecurity.*"</option> (the wikibook
    contains an <link xlink:href="https://en.wikibooks.org/wiki/Grsecurity/Appendix/Sysctl_Options">
    exhaustive listing of grsecurity sysctl tunables</link>).
  </para>

  </sect1>

  <sect1 xml:id="sec-grsec-manual-tuning"><title>Manual tuning</title>

  <para>
    To permit manual tuning of grsecurity runtime parameters, set:
    <programlisting>
      security.grsecurity.lockTunables = false;
    </programlisting>
    Once booted into this system, grsecurity features that have a corresponding
    sysctl tunable can be changed without rebooting, either by switching into
    a new system profile or via the <command>sysctl</command> utility.
  </para>

  <para>
    To lock all grsecurity tunables until the next boot, do:
    <screen>
      # systemctl start grsec-lock
    </screen>
  </para>

  </sect1>

  <sect1 xml:id="sec-grsec-security"><title>Security considerations</title>

  <para>
    The NixOS kernel is built using upstream's recommended settings for a
    desktop deployment that generally favours security over performance.  This
    section details deviations from upstream's recommendations that may
    compromise security.

    <warning><para>There may be additional problems not covered here!</para>
    </warning>
  </para>

  <itemizedlist>

    <listitem><para>
      The following hardening features are disabled in the NixOS kernel:
      <itemizedlist>
        <listitem><para>Kernel symbol hiding: rendered useless by redistributing
        kernel objects.</para></listitem>

        <listitem><para>Randomization of kernel structures: rendered useless by
        redistributing kernel objects.</para></listitem>

        <listitem><para>TCP simultaneous OPEN connection is permitted: breaking
        strict TCP conformance is inappropriate for a general purpose kernel.
        The trade-off is that an attacker may be able to deny outgoing
        connections if they are able to guess the source port allocated by your
        OS for that connection <emphasis>and</emphasis> also manage to initiate
        a TCP simultaneous OPEN on that port before the connection is actually
        established.</para></listitem>

        <listitem><para>Trusted path execution: a desirable feature, but
        requires some more work to operate smoothly on NixOS.</para></listitem>
      </itemizedlist>
    </para></listitem>

    <listitem><para>
      The NixOS module conditionally weakens <command>chroot</command>
      restrictions to accommodate NixOS lightweight containers and sandboxed Nix
      builds.  This can be problematic if the deployment also runs privileged
      network facing processes that <emphasis>rely</emphasis> on
      <command>chroot</command> for isolation.
    </para></listitem>

    <listitem><para>
      The NixOS kernel is patched to allow usermode helpers from anywhere in the
      Nix store.  A usermode helper is an executable called by the kernel in
      certain circumstances, e.g., <command>modprobe</command>.  Vanilla
      grsecurity only allows usermode helpers from paths typically owned by the
      super user.  The NixOS kernel allows an attacker to inject malicious code
      into the Nix store which could then be executed by the kernel as a
      usermode helper.
    </para></listitem>

    <listitem><para>
      The following features are disabled because they overlap with
      vanilla kernel mechanisms:

      <itemizedlist>
        <listitem><para><filename class="directory">/proc</filename> hardening:
        use <option>security.hideProcessInformation</option> instead.  This
        trades weaker protection for greater compatibility.
        </para></listitem>

        <listitem><para><command>dmesg</command> restrictions:
        use <option>boot.kernel.sysctl."kernel.dmesg_restrict"</option> instead
        </para></listitem>
      </itemizedlist>
    </para></listitem>

  </itemizedlist>

  </sect1>

  <sect1 xml:id="sec-grsec-custom-kernel"><title>Using a custom grsecurity/PaX kernel</title>

  <para>
    The NixOS kernel is likely to be either too permissive or too restrictive
    for many deployment scenarios.  In addition to producing a kernel more
    suitable for a particular deployment, a custom kernel may improve security
    by depriving an attacker the ability to study the kernel object code, adding
    yet more guesswork to successfully carry out certain exploits.
  </para>

  <para>
    To build a custom kernel using upstream's recommended settings for server
    deployments, while still using the NixOS module:
    <programlisting>
      nixpkgs.config.packageOverrides = super: {
        linux_grsec_nixos = super.linux_grsec_nixos.override {
          extraConfig = ''
            GRKERNSEC_CONFIG_AUTO y
            GRKERNSEC_CONFIG_SERVER y
            GRKERNSEC_CONFIG_SECURITY y
          '';
          };
      }
    </programlisting>
  </para>

  <para>
    The grsecurity/PaX wikibook provides an exhaustive listing of
    <link xlink:href="https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options">kernel configuration options</link>.
  </para>

  <para>
    The NixOS module makes several assumptions about the kernel and so
    may be incompatible with your customised kernel. Currently, the only way
    to work around these incompatibilities is to eschew the NixOS
    module.
  </para>

  <para>
    If not using the NixOS module, a custom grsecurity package set can
    be specified inline instead, as in
    <programlisting>
      boot.kernelPackages =
        let
          kernel = pkgs.linux_grsec_nixos.override {
            extraConfig = /* as above */;
          };
          self = pkgs.linuxPackagesFor kernel self;
        in self;
    </programlisting>
  </para>

  </sect1>

  <sect1 xml:id="sec-grsec-pax-flags"><title>Per-executable PaX flags</title>

  <para>
    Manual tuning of per-file PaX flags for executables in the Nix store is
    impossible on a properly configured system.  If a package in Nixpkgs fails
    due to PaX, that is a bug in the package recipe and should be reported to
    the maintainer (including relevant <command>dmesg</command> output).
  </para>

  <para>
    For executables installed outside of the Nix store, PaX flags can be set
    using the <command>paxctl</command> utility:
    <programlisting>
      paxctl -czem <replaceable>foo</replaceable>
    </programlisting>

    <warning>
      <para><command>paxctl</command> overwrites files in-place.</para>
    </warning>

    Equivalently, on file systems that support extended attributes:
    <programlisting>
      setfattr -n user.pax.flags -v em <replaceable>foo</replaceable>
    </programlisting>

    <!-- TODO: PaX flags via RBAC policy -->
  </para>

  </sect1>

  <sect1 xml:id="sec-grsec-issues"><title>Issues and work-arounds</title>

  <itemizedlist>
    <listitem><para>User namespaces require <literal>CAP_SYS_ADMIN</literal>:
    consequently, unprivileged namespaces are unsupported. Applications that
    rely on namespaces for sandboxing must use a privileged helper. For chromium
    there is <option>security.chromiumSuidSandbox.enable</option>.</para></listitem>

    <listitem><para>Access to EFI runtime services is disabled by default:
    this plugs a potential code injection attack vector; use
    <option>security.grsecurity.disableEfiRuntimeServices</option> to override
    this behavior.</para></listitem>

    <listitem><para>User initiated autoloading of modules (e.g., when
    using fuse or loop devices) is disallowed; either load requisite modules
    as root or add them to <option>boot.kernelModules</option>.</para></listitem>

    <listitem><para>Virtualization: KVM is the preferred virtualization
    solution. Xen, Virtualbox, and VMWare are
    <emphasis>unsupported</emphasis> and most likely require a custom kernel.
    </para></listitem>

    <listitem><para>
      Attaching <command>gdb</command> to a running process is disallowed by
      default: unprivileged users can only ptrace processes that are children of
      the ptracing process.  To relax this restriction, set
      <programlisting>
        boot.kernel.sysctl."kernel.grsecurity.harden_ptrace" = 0;
      </programlisting>
    </para></listitem>

    <listitem><para>
      Overflows in boot critical code (e.g., the root filesystem module) can
      render the system unbootable.  Work around by setting
      <programlisting>
        boot.kernel.kernelParams = [ "pax_size_overflow_report_only" ];
      </programlisting>
    </para></listitem>

    <listitem><para>
      The <citerefentry><refentrytitle>modify_ldt
      </refentrytitle><manvolnum>2</manvolnum></citerefentry> syscall is disabled
      by default.  This restriction can interfere with programs designed to run
      legacy 16-bit or segmented 32-bit code.  To support applications that rely
      on this syscall, set
      <programlisting>
        boot.kernel.sysctl."kernel.modify_ldt" = 1;
      </programlisting>
    </para></listitem>

    <listitem><para>
      The gitlab service (<xref linkend="module-services-gitlab" />)
      requires a variant of the <literal>ruby</literal> interpreter
      built without `mprotect()` hardening, as in
      <programlisting>
        services.gitlab.packages.gitlab = pkgs.gitlab.override {
          ruby = pkgs.ruby.overrideAttrs (attrs: {
            postFixup = "paxmark m $out/bin/ruby";
          });
        };
      </programlisting>
    </para></listitem>

  </itemizedlist>

  </sect1>

  <sect1 xml:id="sec-grsec-kernel-params"><title>Grsecurity/PaX kernel parameters</title>

  <para>
    The NixOS kernel supports the following kernel command line parameters:
    <itemizedlist>
      <listitem><para>
        <literal>pax_nouderef</literal>: disable UDEREF (separate kernel and
        user address spaces).
      </para></listitem>

      <listitem><para>
        <literal>pax_weakuderef</literal>: enable a faster but
        weaker variant of UDEREF on 64-bit processors with PCID support
        (check <code>grep pcid /proc/cpuinfo</code>).
      </para></listitem>

      <listitem><para>
        <literal>pax_sanitize_slab={off|fast|full}</literal>: control kernel
        slab object sanitization. Defaults to <literal>fast</literal>
      </para></listitem>

      <listitem><para>
        <literal>pax_size_overflow_report_only</literal>: log size overflow
        violations but leave the violating task running
      </para></listitem>

      <listitem><para>
        <literal>grsec_sysfs_restrict=[0|1]</literal>: toggle sysfs
        restrictions. The NixOS module sets this to <literal>0</literal>
        for systemd compatibility
      </para></listitem>
    </itemizedlist>
  </para>

  </sect1>

</chapter>