31 Oct, 2019

1 commit

  • The driver exposes EFI runtime services to user-space through an IOCTL
    interface, calling the EFI services function pointers directly without
    using the efivar API.

    Disallow access to the /dev/efi_test character device when the kernel is
    locked down to prevent arbitrary user-space to call EFI runtime services.

    Also require CAP_SYS_ADMIN to open the chardev to prevent unprivileged
    users to call the EFI runtime services, instead of just relying on the
    chardev file mode bits for this.

    The main user of this driver is the fwts [0] tool that already checks if
    the effective user ID is 0 and fails otherwise. So this change shouldn't
    cause any regression to this tool.

    [0]: https://wiki.ubuntu.com/FirmwareTestSuite/Reference/uefivarinfo

    Signed-off-by: Javier Martinez Canillas
    Signed-off-by: Ard Biesheuvel
    Acked-by: Laszlo Ersek
    Acked-by: Matthew Garrett
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: linux-efi@vger.kernel.org
    Link: https://lkml.kernel.org/r/20191029173755.27149-7-ardb@kernel.org
    Signed-off-by: Ingo Molnar

    Javier Martinez Canillas
     

10 Sep, 2019

1 commit


20 Aug, 2019

20 commits

  • Print the content of current->comm in messages generated by lockdown to
    indicate a restriction that was hit. This makes it a bit easier to find
    out what caused the message.

    The message now patterned something like:

    Lockdown: : is restricted; see man kernel_lockdown.7

    Signed-off-by: David Howells
    Signed-off-by: Matthew Garrett
    Reviewed-by: Kees Cook
    Signed-off-by: James Morris

    Matthew Garrett
     
  • Tracefs may release more information about the kernel than desirable, so
    restrict it when the kernel is locked down in confidentiality mode by
    preventing open().

    (Fixed by Ben Hutchings to avoid a null dereference in
    default_file_open())

    Signed-off-by: Matthew Garrett
    Reviewed-by: Steven Rostedt (VMware)
    Cc: Ben Hutchings
    Signed-off-by: James Morris

    Matthew Garrett
     
  • Disallow opening of debugfs files that might be used to muck around when
    the kernel is locked down as various drivers give raw access to hardware
    through debugfs. Given the effort of auditing all 2000 or so files and
    manually fixing each one as necessary, I've chosen to apply a heuristic
    instead. The following changes are made:

    (1) chmod and chown are disallowed on debugfs objects (though the root dir
    can be modified by mount and remount, but I'm not worried about that).

    (2) When the kernel is locked down, only files with the following criteria
    are permitted to be opened:

    - The file must have mode 00444
    - The file must not have ioctl methods
    - The file must not have mmap

    (3) When the kernel is locked down, files may only be opened for reading.

    Normal device interaction should be done through configfs, sysfs or a
    miscdev, not debugfs.

    Note that this makes it unnecessary to specifically lock down show_dsts(),
    show_devs() and show_call() in the asus-wmi driver.

    I would actually prefer to lock down all files by default and have the
    the files unlocked by the creator. This is tricky to manage correctly,
    though, as there are 19 creation functions and ~1600 call sites (some of
    them in loops scanning tables).

    Signed-off-by: David Howells
    cc: Andy Shevchenko
    cc: acpi4asus-user@lists.sourceforge.net
    cc: platform-driver-x86@vger.kernel.org
    cc: Matthew Garrett
    cc: Thomas Gleixner
    Cc: Greg KH
    Cc: Rafael J. Wysocki
    Signed-off-by: Matthew Garrett
    Signed-off-by: James Morris

    David Howells
     
  • Disallow the use of certain perf facilities that might allow userspace to
    access kernel data.

    Signed-off-by: David Howells
    Signed-off-by: Matthew Garrett
    Reviewed-by: Kees Cook
    Cc: Peter Zijlstra
    Cc: Ingo Molnar
    Cc: Arnaldo Carvalho de Melo
    Signed-off-by: James Morris

    David Howells
     
  • bpf_read() and bpf_read_str() could potentially be abused to (eg) allow
    private keys in kernel memory to be leaked. Disable them if the kernel
    has been locked down in confidentiality mode.

    Suggested-by: Alexei Starovoitov
    Signed-off-by: Matthew Garrett
    Reviewed-by: Kees Cook
    cc: netdev@vger.kernel.org
    cc: Chun-Yi Lee
    cc: Alexei Starovoitov
    Cc: Daniel Borkmann
    Signed-off-by: James Morris

    David Howells
     
  • Disallow the creation of perf and ftrace kprobes when the kernel is
    locked down in confidentiality mode by preventing their registration.
    This prevents kprobes from being used to access kernel memory to steal
    crypto data, but continues to allow the use of kprobes from signed
    modules.

    Reported-by: Alexei Starovoitov
    Signed-off-by: David Howells
    Signed-off-by: Matthew Garrett
    Acked-by: Masami Hiramatsu
    Reviewed-by: Kees Cook
    Cc: Naveen N. Rao
    Cc: Anil S Keshavamurthy
    Cc: davem@davemloft.net
    Cc: Masami Hiramatsu
    Signed-off-by: James Morris

    David Howells
     
  • Disallow access to /proc/kcore when the kernel is locked down to prevent
    access to cryptographic data. This is limited to lockdown
    confidentiality mode and is still permitted in integrity mode.

    Signed-off-by: David Howells
    Signed-off-by: Matthew Garrett
    Reviewed-by: Kees Cook
    Signed-off-by: James Morris

    David Howells
     
  • The testmmiotrace module shouldn't be permitted when the kernel is locked
    down as it can be used to arbitrarily read and write MMIO space. This is
    a runtime check rather than buildtime in order to allow configurations
    where the same kernel may be run in both locked down or permissive modes
    depending on local policy.

    Suggested-by: Thomas Gleixner
    Signed-off-by: David Howells
    Acked-by: Steven Rostedt (VMware)
    Reviewed-by: Kees Cook
    cc: Thomas Gleixner
    cc: Steven Rostedt
    cc: Ingo Molnar
    cc: "H. Peter Anvin"
    cc: x86@kernel.org
    Signed-off-by: James Morris

    David Howells
     
  • Provided an annotation for module parameters that specify hardware
    parameters (such as io ports, iomem addresses, irqs, dma channels, fixed
    dma buffers and other types).

    Suggested-by: Alan Cox
    Signed-off-by: David Howells
    Signed-off-by: Matthew Garrett
    Reviewed-by: Kees Cook
    Cc: Jessica Yu
    Signed-off-by: James Morris

    David Howells
     
  • Lock down TIOCSSERIAL as that can be used to change the ioport and irq
    settings on a serial port. This only appears to be an issue for the serial
    drivers that use the core serial code. All other drivers seem to either
    ignore attempts to change port/irq or give an error.

    Reported-by: Greg Kroah-Hartman
    Signed-off-by: David Howells
    Signed-off-by: Matthew Garrett
    Reviewed-by: Kees Cook
    cc: Jiri Slaby
    Cc: linux-serial@vger.kernel.org
    Signed-off-by: James Morris

    David Howells
     
  • Prohibit replacement of the PCMCIA Card Information Structure when the
    kernel is locked down.

    Suggested-by: Dominik Brodowski
    Signed-off-by: David Howells
    Signed-off-by: Matthew Garrett
    Reviewed-by: Kees Cook
    Signed-off-by: James Morris

    David Howells
     
  • custom_method effectively allows arbitrary access to system memory, making
    it possible for an attacker to circumvent restrictions on module loading.
    Disable it if the kernel is locked down.

    Signed-off-by: Matthew Garrett
    Signed-off-by: David Howells
    Reviewed-by: Kees Cook
    cc: linux-acpi@vger.kernel.org
    Signed-off-by: James Morris

    Matthew Garrett
     
  • Writing to MSRs should not be allowed if the kernel is locked down, since
    it could lead to execution of arbitrary code in kernel mode. Based on a
    patch by Kees Cook.

    Signed-off-by: Matthew Garrett
    Signed-off-by: David Howells
    Acked-by: Kees Cook
    Reviewed-by: Thomas Gleixner
    cc: x86@kernel.org
    Signed-off-by: James Morris

    Matthew Garrett
     
  • IO port access would permit users to gain access to PCI configuration
    registers, which in turn (on a lot of hardware) give access to MMIO
    register space. This would potentially permit root to trigger arbitrary
    DMA, so lock it down by default.

    This also implicitly locks down the KDADDIO, KDDELIO, KDENABIO and
    KDDISABIO console ioctls.

    Signed-off-by: Matthew Garrett
    Signed-off-by: David Howells
    Reviewed-by: Kees Cook
    cc: x86@kernel.org
    Signed-off-by: James Morris

    Matthew Garrett
     
  • Any hardware that can potentially generate DMA has to be locked down in
    order to avoid it being possible for an attacker to modify kernel code,
    allowing them to circumvent disabled module loading or module signing.
    Default to paranoid - in future we can potentially relax this for
    sufficiently IOMMU-isolated devices.

    Signed-off-by: David Howells
    Signed-off-by: Matthew Garrett
    Acked-by: Bjorn Helgaas
    Reviewed-by: Kees Cook
    cc: linux-pci@vger.kernel.org
    Signed-off-by: James Morris

    Matthew Garrett
     
  • There is currently no way to verify the resume image when returning
    from hibernate. This might compromise the signed modules trust model,
    so until we can work with signed hibernate images we disable it when the
    kernel is locked down.

    Signed-off-by: Josh Boyer
    Signed-off-by: David Howells
    Signed-off-by: Matthew Garrett
    Reviewed-by: Kees Cook
    Cc: rjw@rjwysocki.net
    Cc: pavel@ucw.cz
    cc: linux-pm@vger.kernel.org
    Signed-off-by: James Morris

    Josh Boyer
     
  • The kexec_load() syscall permits the loading and execution of arbitrary
    code in ring 0, which is something that lock-down is meant to prevent. It
    makes sense to disable kexec_load() in this situation.

    This does not affect kexec_file_load() syscall which can check for a
    signature on the image to be booted.

    Signed-off-by: David Howells
    Signed-off-by: Matthew Garrett
    Acked-by: Dave Young
    Reviewed-by: Kees Cook
    cc: kexec@lists.infradead.org
    Signed-off-by: James Morris

    Matthew Garrett
     
  • Allowing users to read and write to core kernel memory makes it possible
    for the kernel to be subverted, avoiding module loading restrictions, and
    also to steal cryptographic information.

    Disallow /dev/mem and /dev/kmem from being opened this when the kernel has
    been locked down to prevent this.

    Also disallow /dev/port from being opened to prevent raw ioport access and
    thus DMA from being used to accomplish the same thing.

    Signed-off-by: David Howells
    Signed-off-by: Matthew Garrett
    Reviewed-by: Kees Cook
    Cc: x86@kernel.org
    Signed-off-by: James Morris

    Matthew Garrett
     
  • If the kernel is locked down, require that all modules have valid
    signatures that we can verify.

    I have adjusted the errors generated:

    (1) If there's no signature (ENODATA) or we can't check it (ENOPKG,
    ENOKEY), then:

    (a) If signatures are enforced then EKEYREJECTED is returned.

    (b) If there's no signature or we can't check it, but the kernel is
    locked down then EPERM is returned (this is then consistent with
    other lockdown cases).

    (2) If the signature is unparseable (EBADMSG, EINVAL), the signature fails
    the check (EKEYREJECTED) or a system error occurs (eg. ENOMEM), we
    return the error we got.

    Note that the X.509 code doesn't check for key expiry as the RTC might not
    be valid or might not have been transferred to the kernel's clock yet.

    [Modified by Matthew Garrett to remove the IMA integration. This will
    be replaced with integration with the IMA architecture policy
    patchset.]

    Signed-off-by: David Howells
    Signed-off-by: Matthew Garrett
    Reviewed-by: Kees Cook
    Cc: Jessica Yu
    Signed-off-by: James Morris

    David Howells
     
  • While existing LSMs can be extended to handle lockdown policy,
    distributions generally want to be able to apply a straightforward
    static policy. This patch adds a simple LSM that can be configured to
    reject either integrity or all lockdown queries, and can be configured
    at runtime (through securityfs), boot time (via a kernel parameter) or
    build time (via a kconfig option). Based on initial code by David
    Howells.

    Signed-off-by: Matthew Garrett
    Reviewed-by: Kees Cook
    Cc: David Howells
    Signed-off-by: James Morris

    Matthew Garrett