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

Rebase CoreOS patches onto Linux v4.10 #46

Merged
merged 16 commits into from
Feb 25, 2017
Merged

Rebase CoreOS patches onto Linux v4.10 #46

merged 16 commits into from
Feb 25, 2017

Commits on Feb 24, 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 <matthew.garrett@nebula.com>
    @bgilbert
    Matthew Garrett authored and bgilbert committed Feb 24, 2017
    Configuration menu
    Copy the full SHA
    73bb7b8 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 <matthew.garrett@nebula.com>
    @bgilbert
    Matthew Garrett authored and bgilbert committed Feb 24, 2017
    Configuration menu
    Copy the full SHA
    b3852ff 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 <matthew.garrett@nebula.com>
    @bgilbert
    Matthew Garrett authored and bgilbert committed Feb 24, 2017
    Configuration menu
    Copy the full SHA
    91f145f 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 <matthew.garrett@nebula.com>
    @bgilbert
    Matthew Garrett authored and bgilbert committed Feb 24, 2017
    Configuration menu
    Copy the full SHA
    03d7d4e 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 <matthew.garrett@nebula.com>
    @bgilbert
    Matthew Garrett authored and bgilbert committed Feb 24, 2017
    Configuration menu
    Copy the full SHA
    914723f 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 <matthew.garrett@nebula.com>
    @bgilbert
    Matthew Garrett authored and bgilbert committed Feb 24, 2017
    Configuration menu
    Copy the full SHA
    be3c594 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 <jwboyer@redhat.com>
    @jwboyer @bgilbert
    jwboyer authored and bgilbert committed Feb 24, 2017
    Configuration menu
    Copy the full SHA
    8802118 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 <matthew.garrett@nebula.com>
    @bgilbert
    Matthew Garrett authored and bgilbert committed Feb 24, 2017
    Configuration menu
    Copy the full SHA
    f1fcf91 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 <keescook@chromium.org>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
    @bgilbert
    Matthew Garrett authored and bgilbert committed Feb 24, 2017
    Configuration menu
    Copy the full SHA
    6cdc502 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 <matthew.garrett@nebula.com>
    @bgilbert
    Matthew Garrett authored and bgilbert committed Feb 24, 2017
    Configuration menu
    Copy the full SHA
    8513cdd 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 <jwboyer@fedoraproject.org>
    @bgilbert
    Josh Boyer authored and bgilbert committed Feb 24, 2017
    Configuration menu
    Copy the full SHA
    4c58cd4 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 <jwboyer@fedoraproject.org>
    @bgilbert
    Josh Boyer authored and bgilbert committed Feb 24, 2017
    Configuration menu
    Copy the full SHA
    d70536a 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 <jwboyer@fedoraproject.org>
    @bgilbert
    Josh Boyer authored and bgilbert committed Feb 24, 2017
    Configuration menu
    Copy the full SHA
    e9e2b41 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.
    @bgilbert
    Vito Caputo authored and bgilbert committed Feb 24, 2017
    Configuration menu
    Copy the full SHA
    0e124e6 View commit details
    Browse the repository at this point in the history

  15. Add arm64 coreos verity hash 

    Signed-off-by: Geoff Levand <geoff@infradead.org>
    @glevand @bgilbert
    glevand authored and bgilbert committed Feb 24, 2017
    Configuration menu
    Copy the full SHA
    27499a2 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 <sds@tycho.nsa.gov>
Signed-off-by: Paul Moore <paul@paul-moore.com>
    @stephensmalley @bgilbert
    stephensmalley authored and bgilbert committed Feb 24, 2017
    Configuration menu
    Copy the full SHA
    c67b19f View commit details
    Browse the repository at this point in the history