lkml.org 
[lkml]   [2018]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [GIT PULL] Kernel lockdown for secure boot
From
Date

> On Apr 2, 2018, at 5:59 PM, Kees Cook <keescook@chromium.org> wrote:
>
>> On Mon, Apr 2, 2018 at 5:37 PM, Andy Lutomirski <luto@kernel.org> wrote:
>>> On 03/30/2018 05:46 PM, James Morris wrote:
>>>
>>>> On Sat, 31 Mar 2018, David Howells wrote:
>>>>
>>>> Date: Thu, 26 Oct 2017 17:37:38 +0100
>>>>
>>>> Hi James,
>>>>
>>>> Can you pull this patchset into security/next please? It has been in
>>>> linux-next since the beginning of March.
>>>>
>>>> It adds kernel lockdown support for EFI secure boot.
>>>
>>>
>>> Applied to
>>> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git
>>> next-lockdown and next-testing
>>>
>>> Are there any known coverage gaps now?
>>>
>>>
>>>
>>
>> This is an attempt at a review. I'm replying here because I can't find the
>> actual relevant patch emails.
>>
>> Cover letter:
>>
>>> Here's a set of patches to institute a "locked-down mode" in the
>>> kernel and to trigger that mode if the kernel is booted in secure-boot >
>>> mode or through the command line.
>>
>> I think this is seriously problematic in that it's not well defined. It
>> sounds like "locked-down mode" means "make me feel good about something".
>
> Naming of this feature has been multi-year bikeshedding, so if we
> could just leave the name, that'd be nice.

Fair enough. How about enum kernel_lockdown_level with three modes?

>
>

>> "Restrict /dev/{mem,kmem,port} when the kernel is locked down": this should
>> probably split into one restriction for read and one for write.
>
> I think splitting read and write is only useful if there is a use-case
> for only blocking one of them. I struggle to imagine allowing write
> and blocking read, so really it's the case of wanting to allow read
> and disallow write. Is there actually a use-case for this? In all the
> "locked down" cases I've seen, both are desired.
>

Let’s suppose for the sake of argument that UEFI really has a good reason to block writes. Blocking reads (kprobes, perf, etc) sounds extremely annoying, especially if running a stock distro, and I’d much rather not do it unless there’s a specific use case that needs it.
\
 
 \ /
  Last update: 2018-04-03 03:48    [W:0.154 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site