linux-kernel - Re: linux-next: UEFI Secure boot lockdown patchset

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 1 Mar 2018 11:08:30 +0000
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     David Howells <dhowells@...hat.com>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>, jmorris@...ei.org,
        jforbes@...hat.com, Matthew Garrett <mjg59@...gle.com>,
        linux-security-module <linux-security-module@...r.kernel.org>,
        linux-efi@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Michael Kerrisk-manpages <mtk.manpages@...il.com>
Subject: Re: linux-next: UEFI Secure boot lockdown patchset

Hi David,

On 1 March 2018 at 11:06, David Howells <dhowells@...hat.com> wrote:
>
> Hi Stephen,
>
> Can you pull the following branch into linux-next please?

Could you please include a URL?

>  It does three
> things:
>
>  (1) It restricts various accesses userspace may make upon the kernel when the
>      kernel is locked down.
>
>  (2) It engages the lockdown if UEFI Secure Boot mode is detected.
>
>  (3) It passes the UEFI Secure Boot mode indication across kexec.
>
> The restrictions include:
>
>  - Enforcing the use of module signatures
>  - Enforcing the use of kexec image signatures
>  - Requring IMA to use secure boot rules
>  - Disabling:
>    - The kexec_load() syscall
>    - Use of /dev/{mem,kmem,port,kcore}
>    - Hibernation
>    - PCI BAR access
>    - Direct I/O port access
>  - Preventing direct port specification in drivers:
>    - SCSI EATA
>    - TIOCSSERIAL
>    - Module parameters
>  - Restricting:
>    - MSR access
>    - Certain ACPI features
>    - kprobes
>    - BPF
>    - Perf
>    - Debugfs
>
> The aim of the restrictions is twofold:
>
>   (1) Prevent userspace from altering the kernel image directly (eg. by
>       /dev/mem) or indirectly (eg. by manipulating a device to do DMA);
>
>   (2) Prevent userspace from accessing crypto data stored in the kernel
>       (eg. filesystem keys).
>
> A warning is logged if a restriction is triggered for which I've written a
> manpage that is referenced in the message (see attached).
>
> David
>