linux-kernel - Re: [PATCH 00/16] Kernel lockdown

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:   Wed, 16 Nov 2016 22:27:31 +0000
From:   One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:     David Howells <dhowells@...hat.com>
Cc:     keyrings@...r.kernel.org, matthew.garrett@...ula.com,
        linux-security-module@...r.kernel.org, linux-efi@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/16] Kernel lockdown

Whether it's a good idea aside

You need to filter or lock down kernel module options because a lot of
modules let you set the I/O port or similar (eg mmio) which means you can
hack the entire machine with say the 8250 driver just by using it with an
mmio of the right location to patch the secure state to zero just by
getting the ability to write to the modules conf file.

Without that at least fixed I don't see the point in merging this. Either
we don't do it (which given the level of security the current Linux
kernel provides, and also all the golden key messups from elsewhere might
be the honest approach), or at least try and do the job right.

Less security is better than fake security. If you've got less security
your take appropriate precautions. If you rely on fake security you don't.

The two other nasty cases you miss should be fine for x86 secure boot -
but maybe not for secure boot in general. That is firmware loading and
initial firewire state. Both should be fine on any 'secure' boot PC.

Alan