Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1617335 > unrolled thread

[PATCH 00/24] Kernel lockdown

Back to article view | Back to linux.kernel

Contents

  [PATCH 00/24] Kernel lockdown David Howells <dhowells@redhat.com> - 2017-04-05 22:20 +0200
    [PATCH 24/24] Lock down module params that specify hardware  parameters (eg. ioport) David Howells <dhowells@redhat.com> - 2017-04-05 22:20 +0200
    [PATCH 03/24] efi: Lock down the kernel if booted in secure boot  mode David Howells <dhowells@redhat.com> - 2017-04-05 22:20 +0200
    [PATCH 20/24] bpf: Restrict kernel image access functions when the  kernel is locked down David Howells <dhowells@redhat.com> - 2017-04-05 22:20 +0200
      Re: [PATCH 20/24] bpf: Restrict kernel image access functions when  the kernel is locked down Alexei Starovoitov <alexei.starovoitov@gmail.com> - 2017-04-06 14:30 +0200
        Re: [PATCH 20/24] bpf: Restrict kernel image access functions when  the kernel is locked down Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-04-06 14:50 +0200
    [PATCH 12/24] PCI: Lock down BAR access when the kernel is locked  down David Howells <dhowells@redhat.com> - 2017-04-05 22:20 +0200
    [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel  is locked down David Howells <dhowells@redhat.com> - 2017-04-05 22:20 +0200
      Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the  kernel is locked down Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-04-07 12:30 +0200
        Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down David Howells <dhowells@redhat.com> - 2017-04-07 15:00 +0200
          Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the  kernel is locked down Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-04-09 13:20 +0200
            Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down David Howells <dhowells@redhat.com> - 2017-04-10 15:20 +0200
    [PATCH 02/24] Add the ability to lock down access to the running  kernel image David Howells <dhowells@redhat.com> - 2017-04-05 22:20 +0200
    [PATCH 07/24] kexec: Disable at runtime if the kernel is locked down David Howells <dhowells@redhat.com> - 2017-04-05 22:20 +0200
      Re: [PATCH 07/24] kexec: Disable at runtime if the kernel is locked  down Dave Young <dyoung@redhat.com> - 2017-04-07 05:10 +0200
    [PATCH 08/24] Copy secure_boot flag in boot params across kexec  reboot David Howells <dhowells@redhat.com> - 2017-04-05 22:20 +0200
    [PATCH 06/24] Add a sysrq option to exit secure boot mode David Howells <dhowells@redhat.com> - 2017-04-05 22:20 +0200
    [PATCH 10/24] hibernate: Disable when the kernel is locked down David Howells <dhowells@redhat.com> - 2017-04-05 22:20 +0200
    [PATCH 14/24] x86: Restrict MSR access when the kernel is locked  down David Howells <dhowells@redhat.com> - 2017-04-05 22:30 +0200
    [PATCH 04/24] Enforce module signatures if the kernel is locked down David Howells <dhowells@redhat.com> - 2017-04-05 22:30 +0200
    [PATCH 11/24] uswsusp: Disable when the kernel is locked down David Howells <dhowells@redhat.com> - 2017-04-05 22:30 +0200
      Re: [PATCH 11/24] uswsusp: Disable when the kernel is locked down "Rafael J. Wysocki" <rafael@kernel.org> - 2017-04-06 01:40 +0200
        Re: [PATCH 11/24] uswsusp: Disable when the kernel is locked down Oliver Neukum <oneukum@suse.com> - 2017-04-06 08:50 +0200
          Re: [PATCH 11/24] uswsusp: Disable when the kernel is locked down David Howells <dhowells@redhat.com> - 2017-04-06 11:30 +0200
            Re: [PATCH 11/24] uswsusp: Disable when the kernel is locked down "Rafael J. Wysocki" <rafael@kernel.org> - 2017-04-06 22:20 +0200
              Re: [PATCH 11/24] uswsusp: Disable when the kernel is locked down Jiri Kosina <jikos@kernel.org> - 2017-04-06 22:30 +0200
                Re: [PATCH 11/24] uswsusp: Disable when the kernel is locked down poma <pomidorabelisima@gmail.com> - 2017-04-08 05:30 +0200
            Re: [PATCH 11/24] uswsusp: Disable when the kernel is locked down "Rafael J. Wysocki" <rafael@kernel.org> - 2017-04-06 22:20 +0200
        Re: [PATCH 11/24] uswsusp: Disable when the kernel is locked down David Howells <dhowells@redhat.com> - 2017-04-06 09:00 +0200
          Re: [PATCH 11/24] uswsusp: Disable when the kernel is locked down "Rafael J. Wysocki" <rafael@kernel.org> - 2017-04-06 22:20 +0200
    [PATCH 09/24] kexec_file: Disable at runtime if securelevel has  been set David Howells <dhowells@redhat.com> - 2017-04-05 22:30 +0200
      Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has  been set Dave Young <dyoung@redhat.com> - 2017-04-07 05:10 +0200
        Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has  been set Mimi Zohar <zohar@linux.vnet.ibm.com> - 2017-04-07 05:50 +0200
          Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has  been set Dave Young <dyoung@redhat.com> - 2017-04-07 08:20 +0200
            Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set David Howells <dhowells@redhat.com> - 2017-04-07 09:10 +0200
              Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has  been set Dave Young <dyoung@redhat.com> - 2017-04-07 09:50 +0200
                Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has  been set Mimi Zohar <zohar@linux.vnet.ibm.com> - 2017-04-07 10:30 +0200
                  Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has  been set Dave Young <dyoung@redhat.com> - 2017-04-07 10:50 +0200
            Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has  been set Mimi Zohar <zohar@linux.vnet.ibm.com> - 2017-04-07 09:50 +0200
              Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has  been set Dave Young <dyoung@redhat.com> - 2017-04-07 10:10 +0200
          Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set David Howells <dhowells@redhat.com> - 2017-04-07 09:20 +0200
            Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has  been set Mimi Zohar <zohar@linux.vnet.ibm.com> - 2017-04-07 09:50 +0200
              Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set David Howells <dhowells@redhat.com> - 2017-04-07 11:20 +0200
                Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has  been set Mimi Zohar <zohar@linux.vnet.ibm.com> - 2017-04-07 14:40 +0200
                  Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set David Howells <dhowells@redhat.com> - 2017-04-10 15:30 +0200
    Re: [PATCH 00/24] Kernel lockdown "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2017-04-07 18:10 +0200
      Re: [PATCH 00/24] Kernel lockdown Justin Forbes <jmforbes@linuxtx.org> - 2017-04-07 18:40 +0200

Page 3 of 3 — ← Prev page 1 2 [3]

#1618513 — Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set

Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:

> > > +	if (!IS_ENABLED(CONFIG_KEXEC_VERIFY_SIG) && kernel_is_locked_down())
> > > +		return -EPERM;
> > > +
> > >  
> 
> IMA can be used to verify file signatures too, based on the LSM hooks
> in  kernel_read_file_from_fd().  CONFIG_KEXEC_VERIFY_SIG should not be
> required.

Okay, fair enough.  I can stick in an OR with an IS_ENABLED on some IMA
symbol.  CONFIG_IMA_KEXEC maybe?  And also require IMA be enabled?

David

[toc] | [prev] | [next] | [standalone]

#1618545 — Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set

On Fri, 2017-04-07 at 08:09 +0100, David Howells wrote:
> Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> 
> > > > +	if (!IS_ENABLED(CONFIG_KEXEC_VERIFY_SIG) && kernel_is_locked_down())
> > > > +		return -EPERM;
> > > > +
> > > >  
> > 
> > IMA can be used to verify file signatures too, based on the LSM hooks
> > in  kernel_read_file_from_fd().  CONFIG_KEXEC_VERIFY_SIG should not be
> > required.
> 
> Okay, fair enough.  I can stick in an OR with an IS_ENABLED on some IMA
> symbol.  CONFIG_IMA_KEXEC maybe?  And also require IMA be enabled?

Not quite, since as Dave pointed out, IMA is policy driven.  As a
policy is installed, we could set a flag.

Mimi

[toc] | [prev] | [next] | [standalone]

#1618618 — Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set

Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:

> > Okay, fair enough.  I can stick in an OR with an IS_ENABLED on some IMA
> > symbol.  CONFIG_IMA_KEXEC maybe?  And also require IMA be enabled?
> 
> Not quite, since as Dave pointed out, IMA is policy driven.  As a
> policy is installed, we could set a flag.

Does such a flag exist as yet?

David

[toc] | [prev] | [next] | [standalone]

#1618730 — Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set

On Fri, 2017-04-07 at 10:17 +0100, David Howells wrote:
> Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> 
> > > Okay, fair enough.  I can stick in an OR with an IS_ENABLED on some IMA
> > > symbol.  CONFIG_IMA_KEXEC maybe?  And also require IMA be enabled?
> > 
> > Not quite, since as Dave pointed out, IMA is policy driven.  As a
> > policy is installed, we could set a flag.
> 
> Does such a flag exist as yet?

Not exactly what is needed.  There's a flag named ima_appraise, which
is used internally in IMA. A temporary flag is created, while
validating the rules.

	if (default_appraise_rules[i].func == POLICY_CHECK)
        	temp_ima_appraise |= IMA_APPRAISE_POLICY;

        if (!result && (entry->action == UNKNOWN))
                result = -EINVAL;
        else if (entry->func == MODULE_CHECK)
                temp_ima_appraise |= IMA_APPRAISE_MODULES;
        else if (entry->func == FIRMWARE_CHECK)
                temp_ima_appraise |= IMA_APPRAISE_FIRMWARE;
        else if (entry->func == POLICY_CHECK)
                temp_ima_appraise |= IMA_APPRAISE_POLICY;

If the entire policy is valid,   ima_update_policy_flag() sets the ima_appraise flag.

        ima_appraise |= temp_ima_appraise;

From an IMA perspective, either a file hash or signature are valid,
but for this usage it must be a signature.  So in addition to testing
entry->func, above, entry->flags would need to be tested as well to
detect if IMA_DIGSIG_REQUIRED is set.

Mimi

[toc] | [prev] | [next] | [standalone]

#1619939 — Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set

Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:

> From an IMA perspective, either a file hash or signature are valid,
> but for this usage it must be a signature.

Not necessarily.  If IMA can guarantee that a module is the same based on its
hash rather than on a key, I would've thought that should be fine.

David

[toc] | [prev] | [next] | [standalone]

#1618934

On 2017-04-05 16:14, David Howells wrote:
>
> These patches provide a facility by which a variety of avenues by which
> userspace can feasibly modify the running kernel image can be locked down.
> These include:
>
>  (*) No unsigned modules and no modules for which can't validate the
>      signature.
>
>  (*) No use of ioperm(), iopl() and no writing to /dev/port.
>
>  (*) No writing to /dev/mem or /dev/kmem.
>
>  (*) No hibernation.
>
>  (*) Restrict PCI BAR access.
>
>  (*) Restrict MSR access.
>
>  (*) No kexec_load().
>
>  (*) Certain ACPI restrictions.
>
>  (*) Restrict debugfs interface to ASUS WMI.
>
> The lock-down can be configured to be triggered by the EFI secure boot
> status, provided the shim isn't insecure.  The lock-down can be lifted by
> typing SysRq+x on a keyboard attached to the system.
This has already been mentioned both in response to previous versions of 
this patch set, and by at least 2 people in response to a specific patch 
in this posting, but for any kind of proper security analysis, you need 
to better clarify your threat model.  'Prevent modification to the 
running kernel image' is a decent start on this, but at least some of 
the patches don't explain very well _how_ what you're disabling could be 
used to modify the running kernel image.  Clarifying how something is a 
threat will help with verifying that you're correctly blocking the threat.

Furthermore, why is the only way to enable this to boot in UEFI Secure 
Boot mode?  Almost all of the hardening done here has general utility in 
hardening regular systems, and as such I'd suggest adding a command line 
option to enable kernel lock-down (which would greatly simplify 
testing), and a kconfig option to enforce it at build-time.

In addition to all that, it would be nice to be able to disable all of 
the following at build time independent of the kernel lock-down state
* The acpi_rsdp kernel parameter (I could easily see many distros 
building kernels with this disabled, it's insanely use-case specific).
* IO port and resource reservation module parameters (this would 
actually be easier than having runtime blacklisting, and I could also 
easily see this being turned on by default by a number of distros).
* TOICSERIAL (this one is more likely than the above two to break systems).

And these would probably be useful as lockable sysctls that would be 
automatically locked disabled when the kernel is locked down:
* ioperm/iopl (these can technically be blocked by seccomp or other 
means, but that is non-trivial to do).
* Most of the other ACPI stuff (some of this is useful for 
troubleshooting, but is not normally used during regular operation).
* PCI BAR access.

[toc] | [prev] | [next] | [standalone]

#1618958

On Fri, Apr 7, 2017 at 10:59 AM, Austin S. Hemmelgarn
<ahferroin7@gmail.com> wrote:
> On 2017-04-05 16:14, David Howells wrote:
>>
>>
>> These patches provide a facility by which a variety of avenues by which
>> userspace can feasibly modify the running kernel image can be locked down.
>> These include:
>>
>>  (*) No unsigned modules and no modules for which can't validate the
>>      signature.
>>
>>  (*) No use of ioperm(), iopl() and no writing to /dev/port.
>>
>>  (*) No writing to /dev/mem or /dev/kmem.
>>
>>  (*) No hibernation.
>>
>>  (*) Restrict PCI BAR access.
>>
>>  (*) Restrict MSR access.
>>
>>  (*) No kexec_load().
>>
>>  (*) Certain ACPI restrictions.
>>
>>  (*) Restrict debugfs interface to ASUS WMI.
>>
>> The lock-down can be configured to be triggered by the EFI secure boot
>> status, provided the shim isn't insecure.  The lock-down can be lifted by
>> typing SysRq+x on a keyboard attached to the system.
>
> This has already been mentioned both in response to previous versions of
> this patch set, and by at least 2 people in response to a specific patch in
> this posting, but for any kind of proper security analysis, you need to
> better clarify your threat model.  'Prevent modification to the running
> kernel image' is a decent start on this, but at least some of the patches
> don't explain very well _how_ what you're disabling could be used to modify
> the running kernel image.  Clarifying how something is a threat will help
> with verifying that you're correctly blocking the threat.

It is more than just preventing modification to the running kernel
image.  The idea is that everything is verified, from UEFI through the
bootloader, and into the kernel.

> Furthermore, why is the only way to enable this to boot in UEFI Secure Boot
> mode?  Almost all of the hardening done here has general utility in
> hardening regular systems, and as such I'd suggest adding a command line
> option to enable kernel lock-down (which would greatly simplify testing),
> and a kconfig option to enforce it at build-time.

The problem is, if the hand off doesn't happen from a secure firmware,
there is no guarantee the system has not been compromised. UEFI Secure
Boot mode attempts to give that promise, and an appropriate hand off.
That doesn't mean that there is no value in turning some of this on,
it is just of more limited effectiveness.

> In addition to all that, it would be nice to be able to disable all of the
> following at build time independent of the kernel lock-down state
> * The acpi_rsdp kernel parameter (I could easily see many distros building
> kernels with this disabled, it's insanely use-case specific).
> * IO port and resource reservation module parameters (this would actually be
> easier than having runtime blacklisting, and I could also easily see this
> being turned on by default by a number of distros).
> * TOICSERIAL (this one is more likely than the above two to break systems).
>
> And these would probably be useful as lockable sysctls that would be
> automatically locked disabled when the kernel is locked down:
> * ioperm/iopl (these can technically be blocked by seccomp or other means,
> but that is non-trivial to do).
> * Most of the other ACPI stuff (some of this is useful for troubleshooting,
> but is not normally used during regular operation).
> * PCI BAR access.

There are more patches to do some of these things.   Baby steps.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | linux.kernel

csiph-web