linux-kernel - Re: [PATCH 01/24] Add the ability to lock down access to the running kernel image

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]

Message-ID: <CA+55aFzPo-dip8dgyo0U+g5qai9SAJU+D1c+AFJ0zV9_PBAB8Q@mail.gmail.com>
Date:   Wed, 11 Apr 2018 11:09:41 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     David Howells <dhowells@...hat.com>
Cc:     linux-man <linux-man@...r.kernel.org>,
        Linux API <linux-api@...r.kernel.org>,
        James Morris <jmorris@...ei.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        LSM List <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH 01/24] Add the ability to lock down access to the running
 kernel image

On Wed, Apr 11, 2018 at 9:24 AM, David Howells <dhowells@...hat.com> wrote:
> Provide a single call to allow kernel code to determine whether the system
> should be locked down, thereby disallowing various accesses that might
> allow the running kernel image to be changed, including:
>
>  - /dev/mem and similar
>  - Loading of unauthorised modules
>  - Fiddling with MSR registers
>  - Suspend to disk managed by the kernel
>  - Use of device DMA

So what I stlll absolutely detest about  this series is that I think
many of these things should simply be done as separate config options.

For example, if the distro is sure that it doesn't need /dev/mem, then
why the hell is  this tied to "lockdown" that then may have to be
disabled because *other* changes may not be acceptable (eg people may
need that device DMA, or whatever).

If that /dev/mem access prevention was just instead done as an even
stricter mode of the existing CONFIG_STRICT_DEVMEM, it could just be
enabled unconditionally.

So none of these patches raise my hackles per se. But what continues
to makes me very very uncomfortable is how this is all tied together.

Why is this one magical mode that then - because it has such a big
impact - has to be enabled/disabled as a single magical mode and with
very odd rules?

I think a lot of people would be happier if this wasn't so incestuous
and mixing together independent things under one name, and one flag.

I think a lot of the secure boot problems were exacerbated by that mixup.

So I would seriously ask that the distros that have been using these
patches look at which parts of lockdown they could make unconditional
(because it doesn't break machines), and which ones need that escape
clause.

                 Linus