20 Jun, 2020

1 commit


03 Jun, 2020

1 commit


15 May, 2020

1 commit

  • A number of userspace tools, such as systemtap, need a way to see the
    current lockdown state so they can gracefully deal with the kernel being
    locked down. The state is already exposed in
    /sys/kernel/security/lockdown, but is only readable by root. Adjust the
    permissions so unprivileged users can read the state.

    Fixes: 000d388ed3bb ("security: Add a static lockdown policy LSM")
    Cc: Frank Ch. Eigler
    Signed-off-by: Jeremy Cline
    Signed-off-by: James Morris

    Jeremy Cline
     

04 Feb, 2020

1 commit


10 Dec, 2019

1 commit

  • Implement a SELinux hook for lockdown. If the lockdown module is also
    enabled, then a denial by the lockdown module will take precedence over
    SELinux, so SELinux can only further restrict lockdown decisions.
    The SELinux hook only distinguishes at the granularity of integrity
    versus confidentiality similar to the lockdown module, but includes the
    full lockdown reason as part of the audit record as a hint in diagnosing
    what triggered the denial. To support this auditing, move the
    lockdown_reasons[] string array from being private to the lockdown
    module to the security framework so that it can be used by the lsm audit
    code and so that it is always available even when the lockdown module
    is disabled.

    Note that the SELinux implementation allows the integrity and
    confidentiality reasons to be controlled independently from one another.
    Thus, in an SELinux policy, one could allow operations that specify
    an integrity reason while blocking operations that specify a
    confidentiality reason. The SELinux hook implementation is
    stricter than the lockdown module in validating the provided reason value.

    Sample AVC audit output from denials:
    avc: denied { integrity } for pid=3402 comm="fwupd"
    lockdown_reason="/dev/mem,kmem,port" scontext=system_u:system_r:fwupd_t:s0
    tcontext=system_u:system_r:fwupd_t:s0 tclass=lockdown permissive=0

    avc: denied { confidentiality } for pid=4628 comm="cp"
    lockdown_reason="/proc/kcore access"
    scontext=unconfined_u:unconfined_r:test_lockdown_integrity_t:s0-s0:c0.c1023
    tcontext=unconfined_u:unconfined_r:test_lockdown_integrity_t:s0-s0:c0.c1023
    tclass=lockdown permissive=0

    Signed-off-by: Stephen Smalley
    Reviewed-by: James Morris
    [PM: some merge fuzz do the the perf hooks]
    Signed-off-by: Paul Moore

    Stephen Smalley
     

01 Dec, 2019

1 commit

  • Pull powerpc updates from Michael Ellerman:
    "Highlights:

    - Infrastructure for secure boot on some bare metal Power9 machines.
    The firmware support is still in development, so the code here
    won't actually activate secure boot on any existing systems.

    - A change to xmon (our crash handler / pseudo-debugger) to restrict
    it to read-only mode when the kernel is lockdown'ed, otherwise it's
    trivial to drop into xmon and modify kernel data, such as the
    lockdown state.

    - Support for KASLR on 32-bit BookE machines (Freescale / NXP).

    - Fixes for our flush_icache_range() and __kernel_sync_dicache()
    (VDSO) to work with memory ranges >4GB.

    - Some reworks of the pseries CMM (Cooperative Memory Management)
    driver to make it behave more like other balloon drivers and enable
    some cleanups of generic mm code.

    - A series of fixes to our hardware breakpoint support to properly
    handle unaligned watchpoint addresses.

    Plus a bunch of other smaller improvements, fixes and cleanups.

    Thanks to: Alastair D'Silva, Andrew Donnellan, Aneesh Kumar K.V,
    Anthony Steinhauser, Cédric Le Goater, Chris Packham, Chris Smart,
    Christophe Leroy, Christopher M. Riedl, Christoph Hellwig, Claudio
    Carvalho, Daniel Axtens, David Hildenbrand, Deb McLemore, Diana
    Craciun, Eric Richter, Geert Uytterhoeven, Greg Kroah-Hartman, Greg
    Kurz, Gustavo L. F. Walbon, Hari Bathini, Harish, Jason Yan, Krzysztof
    Kozlowski, Leonardo Bras, Mathieu Malaterre, Mauro S. M. Rodrigues,
    Michal Suchanek, Mimi Zohar, Nathan Chancellor, Nathan Lynch, Nayna
    Jain, Nick Desaulniers, Oliver O'Halloran, Qian Cai, Rasmus Villemoes,
    Ravi Bangoria, Sam Bobroff, Santosh Sivaraj, Scott Wood, Thomas Huth,
    Tyrel Datwyler, Vaibhav Jain, Valentin Longchamp, YueHaibing"

    * tag 'powerpc-5.5-1' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: (144 commits)
    powerpc/fixmap: fix crash with HIGHMEM
    x86/efi: remove unused variables
    powerpc: Define arch_is_kernel_initmem_freed() for lockdep
    powerpc/prom_init: Use -ffreestanding to avoid a reference to bcmp
    powerpc: Avoid clang warnings around setjmp and longjmp
    powerpc: Don't add -mabi= flags when building with Clang
    powerpc: Fix Kconfig indentation
    powerpc/fixmap: don't clear fixmap area in paging_init()
    selftests/powerpc: spectre_v2 test must be built 64-bit
    powerpc/powernv: Disable native PCIe port management
    powerpc/kexec: Move kexec files into a dedicated subdir.
    powerpc/32: Split kexec low level code out of misc_32.S
    powerpc/sysdev: drop simple gpio
    powerpc/83xx: map IMMR with a BAT.
    powerpc/32s: automatically allocate BAT in setbat()
    powerpc/ioremap: warn on early use of ioremap()
    powerpc: Add support for GENERIC_EARLY_IOREMAP
    powerpc/fixmap: Use __fix_to_virt() instead of fix_to_virt()
    powerpc/8xx: use the fixmapped IMMR in cpm_reset()
    powerpc/8xx: add __init to cpm1 init functions
    ...

    Linus Torvalds
     

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
     

28 Oct, 2019

1 commit

  • Xmon should be either fully or partially disabled depending on the
    kernel lockdown state.

    Put xmon into read-only mode for lockdown=integrity and prevent user
    entry into xmon when lockdown=confidentiality. Xmon checks the lockdown
    state on every attempted entry:

    (1) during early xmon'ing

    (2) when triggered via sysrq

    (3) when toggled via debugfs

    (4) when triggered via a previously enabled breakpoint

    The following lockdown state transitions are handled:

    (1) lockdown=none -> lockdown=integrity
    set xmon read-only mode

    (2) lockdown=none -> lockdown=confidentiality
    clear all breakpoints, set xmon read-only mode,
    prevent user re-entry into xmon

    (3) lockdown=integrity -> lockdown=confidentiality
    clear all breakpoints, set xmon read-only mode,
    prevent user re-entry into xmon

    Suggested-by: Andrew Donnellan
    Signed-off-by: Christopher M. Riedl
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/20190907061124.1947-3-cmr@informatik.wtf

    Christopher M. Riedl
     

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