Skip to content
This repository has been archived by the owner on Sep 24, 2020. It is now read-only.

Rebase 4.10.1 patches onto 4.10.4 #48

Merged
merged 16 commits into from
Mar 20, 2017
Merged

Rebase 4.10.1 patches onto 4.10.4 #48

merged 16 commits into from
Mar 20, 2017

Commits on Mar 20, 2017

  1. Add secure_modules() call 

    Provide a single call to allow kernel code to determine whether the system
has been configured to either disable module loading entirely or to load
only modules signed with a trusted key.

Bugzilla: N/A
Upstream-status: Fedora mustard.  Replaced by securelevels, but that was nak'd

Signed-off-by: Matthew Garrett <[email protected]>
    @dm0-
    Matthew Garrett authored and dm0- committed Mar 20, 2017
    Configuration menu
    Copy the full SHA
    b2abd80 View commit details
    Browse the repository at this point in the history

  2. PCI: Lock down BAR access when module security is enabled 

    Any hardware that can potentially generate DMA has to be locked down from
userspace 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: Matthew Garrett <[email protected]>
    @dm0-
    Matthew Garrett authored and dm0- committed Mar 20, 2017
    Configuration menu
    Copy the full SHA
    ea565b4 View commit details
    Browse the repository at this point in the history

  3. x86: Lock down IO port access when module security is enabled 

    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.

Signed-off-by: Matthew Garrett <[email protected]>
    @dm0-
    Matthew Garrett authored and dm0- committed Mar 20, 2017
    Configuration menu
    Copy the full SHA
    247ab2f View commit details
    Browse the repository at this point in the history

  4. ACPI: Limit access to custom_method 

    custom_method effectively allows arbitrary access to system memory, making
it possible for an attacker to circumvent restrictions on module loading.
Disable it if any such restrictions have been enabled.

Signed-off-by: Matthew Garrett <[email protected]>
    @dm0-
    Matthew Garrett authored and dm0- committed Mar 20, 2017
    Configuration menu
    Copy the full SHA
    5eeb299 View commit details
    Browse the repository at this point in the history

  5. asus-wmi: Restrict debugfs interface when module loading is restricted 

    We have no way of validating what all of the Asus WMI methods do on a
given machine, and there's a risk that some will allow hardware state to
be manipulated in such a way that arbitrary code can be executed in the
kernel, circumventing module loading restrictions. Prevent that if any of
these features are enabled.

Signed-off-by: Matthew Garrett <[email protected]>
    @dm0-
    Matthew Garrett authored and dm0- committed Mar 20, 2017
    Configuration menu
    Copy the full SHA
    30c3afa View commit details
    Browse the repository at this point in the history

  6. Restrict /dev/mem and /dev/kmem when module loading is restricted 

    Allowing users to write to address space makes it possible for the kernel
to be subverted, avoiding module loading restrictions. Prevent this when
any restrictions have been imposed on loading modules.

Signed-off-by: Matthew Garrett <[email protected]>
    @dm0-
    Matthew Garrett authored and dm0- committed Mar 20, 2017
    Configuration menu
    Copy the full SHA
    c8a67b5 View commit details
    Browse the repository at this point in the history

  7. acpi: Ignore acpi_rsdp kernel parameter when module loading is restri… 

    …cted

This option allows userspace to pass the RSDP address to the kernel, which
makes it possible for a user to circumvent any restrictions imposed on
loading modules. Disable it in that case.

Signed-off-by: Josh Boyer <[email protected]>
    @jwboyer @dm0-
    jwboyer authored and dm0- committed Mar 20, 2017
    Configuration menu
    Copy the full SHA
    5359936 View commit details
    Browse the repository at this point in the history

  8. kexec: Disable at runtime if the kernel enforces module loading restr… 

    …ictions

kexec permits the loading and execution of arbitrary code in ring 0, which
is something that module signing enforcement is meant to prevent. It makes
sense to disable kexec in this situation.

Signed-off-by: Matthew Garrett <[email protected]>
    @dm0-
    Matthew Garrett authored and dm0- committed Mar 20, 2017
    Configuration menu
    Copy the full SHA
    f7278e3 View commit details
    Browse the repository at this point in the history

  9. x86: Restrict MSR access when module loading is restricted 

    Writing to MSRs should not be allowed if module loading is restricted,
since it could lead to execution of arbitrary code in kernel mode. Based
on a patch by Kees Cook.

Cc: Kees Cook <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>
    @dm0-
    Matthew Garrett authored and dm0- committed Mar 20, 2017
    Configuration menu
    Copy the full SHA
    e447d16 View commit details
    Browse the repository at this point in the history

  10. Add option to automatically enforce module signatures when in Secure … 

    …Boot mode

UEFI Secure Boot provides a mechanism for ensuring that the firmware will
only load signed bootloaders and kernels. Certain use cases may also
require that all kernel modules also be signed. Add a configuration option
that enforces this automatically when enabled.

Signed-off-by: Matthew Garrett <[email protected]>
    @dm0-
    Matthew Garrett authored and dm0- committed Mar 20, 2017
    Configuration menu
    Copy the full SHA
    82c969d View commit details
    Browse the repository at this point in the history

  11. efi: Make EFI_SECURE_BOOT_SIG_ENFORCE depend on EFI 

    The functionality of the config option is dependent upon the platform being
UEFI based.  Reflect this in the config deps.

Signed-off-by: Josh Boyer <[email protected]>
    @dm0-
    Josh Boyer authored and dm0- committed Mar 20, 2017
    Configuration menu
    Copy the full SHA
    91d4b04 View commit details
    Browse the repository at this point in the history

  12. efi: Add EFI_SECURE_BOOT bit 

    UEFI machines can be booted in Secure Boot mode.  Add a EFI_SECURE_BOOT bit
for use with efi_enabled.

Signed-off-by: Josh Boyer <[email protected]>
    @dm0-
    Josh Boyer authored and dm0- committed Mar 20, 2017
    Configuration menu
    Copy the full SHA
    fe45937 View commit details
    Browse the repository at this point in the history

  13. hibernate: Disable in a signed modules environment 

    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 in
a secure modules environment.

Signed-off-by: Josh Boyer <[email protected]>
    @dm0-
    Josh Boyer authored and dm0- committed Mar 20, 2017
    Configuration menu
    Copy the full SHA
    69d98ac View commit details
    Browse the repository at this point in the history

  14. kbuild: derive relative path for KBUILD_SRC from CURDIR 

    This enables relocating source and build trees to different roots,
provided they stay reachable relative to one another.  Useful for
builds done within a sandbox where the eventual root is prefixed
by some undesirable path component.
    @dm0-
    Vito Caputo authored and dm0- committed Mar 20, 2017
    Configuration menu
    Copy the full SHA
    ad97f19 View commit details
    Browse the repository at this point in the history

  15. Add arm64 coreos verity hash 

    Signed-off-by: Geoff Levand <[email protected]>
    @glevand @dm0-
    glevand authored and dm0- committed Mar 20, 2017
    Configuration menu
    Copy the full SHA
    3014e6d View commit details
    Browse the repository at this point in the history

  16. selinux: allow context mounts on tmpfs, ramfs, devpts within user nam… 

    …espaces

commit aad8289 ("selinux: Add support for
unprivileged mounts from user namespaces") prohibited any use of context
mount options within non-init user namespaces.  However, this breaks
use of context mount options for tmpfs mounts within user namespaces,
which are being used by Docker/runc.  There is no reason to block such
usage for tmpfs, ramfs or devpts.  Exempt these filesystem types
from this restriction.

Before:
sh$ userns_child_exec  -p -m -U -M '0 1000 1' -G '0 1000 1' bash
sh# mount -t tmpfs -o context=system_u:object_r:user_tmp_t:s0:c13 none /tmp
mount: tmpfs is write-protected, mounting read-only
mount: cannot mount tmpfs read-only

After:
sh$ userns_child_exec  -p -m -U -M '0 1000 1' -G '0 1000 1' bash
sh# mount -t tmpfs -o context=system_u:object_r:user_tmp_t:s0:c13 none /tmp
sh# ls -Zd /tmp
unconfined_u:object_r:user_tmp_t:s0:c13 /tmp

Signed-off-by: Stephen Smalley <[email protected]>
Signed-off-by: Paul Moore <[email protected]>
    @stephensmalley @dm0-
    stephensmalley authored and dm0- committed Mar 20, 2017
    Configuration menu
    Copy the full SHA
    41afe48 View commit details
    Browse the repository at this point in the history