Re: linux-next: UEFI Secure boot lockdown patchset

Re: linux-next: UEFI Secure boot lockdown patchset

[Matthew Garrett]

On Thu, Mar 1, 2018 at 3:06 AM David Howells <dhowells@redhat.com> wrote:

>   - Requring IMA to use secure boot rules

On systems that have IMA enabled, this appears to enforce a policy that
requires that IMA signatures be present for kexec and modules.
Distributions are already shipping signed modules and kernel images, so
this policy appears to enforce that

(a) they be signed twice, and
(b) distributions have a mechanism for shipping extended attributes in
packages

(a) seems unnecessary, and (b) isn't possible in most distributions
(there's ongoing work in Debian, but it's not merged yet). I can see cases
where you'd want to enforce this via IMA, but I don't think it's
appropriate for all cases. Should the use of the IMA secure_boot policy be
gated behind a config option?

Re: linux-next: UEFI Secure boot lockdown patchset

[David Howells]

Matthew Garrett <mjg59@google.com> wrote:

> (a) seems unnecessary, and (b) isn't possible in most distributions
> (there's ongoing work in Debian, but it's not merged yet). I can see cases
> where you'd want to enforce this via IMA, but I don't think it's
> appropriate for all cases. Should the use of the IMA secure_boot policy be
> gated behind a config option?

Quite probably.  Mimi?

David

Re: linux-next: UEFI Secure boot lockdown patchset

[Mimi Zohar]

On Tue, 2018-05-01 at 20:00 +0100, David Howells wrote:
> Matthew Garrett <mjg59@google.com> wrote:
> 
> > (a) seems unnecessary, and (b) isn't possible in most distributions
> > (there's ongoing work in Debian, but it's not merged yet). I can see cases
> > where you'd want to enforce this via IMA, but I don't think it's
> > appropriate for all cases. Should the use of the IMA secure_boot policy be
> > gated behind a config option?
> 
> Quite probably.  Mimi?

a) Requiring two signatures was addressed by a patch titled "lockdown:
fix coordination of kernel module signature verification" [1]

b) With the coordination of the signature verification above, enabling
either method or both methods, should work properly.

There's been further discussions as to what should remain in the
"lockdown" patch set.  Based on the discussion here [2], it seems like
 "[PATCH 06/24] kexec_load: Disable at runtime if the kernel is locked
down" will be removed.

Instead of preventing the loading of a kernel image (kexec_load
 syscall) being dependent on the lockdown flag, it could be dependent
on the kernel_read_file_id READING_KEXEC_IMAGE.  A version of these
patches was posted [3].

[1] http://kernsec.org/pipermail/linux-security-module-archive/2018-April/006456.html
[2] http://kernsec.org/pipermail/linux-security-module-archive/2018-April/006419.html
[3] http://kernsec.org/pipermail/linux-security-module-archive/2018-April/006443.html

Mimi

Re: linux-next: UEFI Secure boot lockdown patchset

[Matthew Garrett]

On Tue, May 1, 2018 at 1:15 PM Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> a) Requiring two signatures was addressed by a patch titled "lockdown:
> fix coordination of kernel module signature verification" [1]

Ah, I'd missed that - thanks!

> There's been further discussions as to what should remain in the
> "lockdown" patch set.  Based on the discussion here [2], it seems like
>   "[PATCH 06/24] kexec_load: Disable at runtime if the kernel is locked
> down" will be removed.

> Instead of preventing the loading of a kernel image (kexec_load
>   syscall) being dependent on the lockdown flag, it could be dependent
> on the kernel_read_file_id READING_KEXEC_IMAGE.  A version of these
> patches was posted [3].

Hm. My concern is that distributions are going to ship IMA in a
configuration that allows users to add their own keys at boot time (it's
difficult to use it in a generic way otherwise), and that's going to allow
kexecing of arbitrary images without requiring physical access. I think
kexec_file_load() needs to be relying on non-IMA signatures.

Re: linux-next: UEFI Secure boot lockdown patchset

[Mimi Zohar]

On Tue, 2018-05-01 at 21:02 +0000, Matthew Garrett wrote:
> On Tue, May 1, 2018 at 1:15 PM Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> > a) Requiring two signatures was addressed by a patch titled "lockdown:
> > fix coordination of kernel module signature verification" [1]
> 
> Ah, I'd missed that - thanks!
> 
> > There's been further discussions as to what should remain in the
> > "lockdown" patch set.  Based on the discussion here [2], it seems like
> >   "[PATCH 06/24] kexec_load: Disable at runtime if the kernel is locked
> > down" will be removed.
> 
> > Instead of preventing the loading of a kernel image (kexec_load
> >   syscall) being dependent on the lockdown flag, it could be dependent
> > on the kernel_read_file_id READING_KEXEC_IMAGE.  A version of these
> > patches was posted [3].
> 
> Hm. My concern is that distributions are going to ship IMA in a
> configuration that allows users to add their own keys at boot time (it's
> difficult to use it in a generic way otherwise), and that's going to allow
> kexecing of arbitrary images without requiring physical access. I think
> kexec_file_load() needs to be relying on non-IMA signatures.

I don't see how.  Unless the kernel was built with extra room for a
local CA public key (CONFIG_SYSTEM_EXTRA_CERTIFICATE), which would be
loaded onto the builtin keyring, there is no way of adding keys to the
IMA keyring.  Adding the extra public key would require the kernel to
be resigned.

Mimi

Re: linux-next: UEFI Secure boot lockdown patchset

[Matthew Garrett]

On Tue, May 1, 2018 at 2:50 PM Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:

> On Tue, 2018-05-01 at 21:02 +0000, Matthew Garrett wrote:
> > Hm. My concern is that distributions are going to ship IMA in a
> > configuration that allows users to add their own keys at boot time (it's
> > difficult to use it in a generic way otherwise), and that's going to
allow
> > kexecing of arbitrary images without requiring physical access. I think
> > kexec_file_load() needs to be relying on non-IMA signatures.

> I don't see how.  Unless the kernel was built with extra room for a
> local CA public key (CONFIG_SYSTEM_EXTRA_CERTIFICATE), which would be
> loaded onto the builtin keyring, there is no way of adding keys to the
> IMA keyring.  Adding the extra public key would require the kernel to
> be resigned.

Oh, is kexec verified off the _module keyring? We still end up with the
problem that distributions don't have a mechanism to ship IMA signatures
yet, but that avoids the user modification problem. I've just posted a
patchset to debian-dpkg, we'll see how that goes.

Re: linux-next: UEFI Secure boot lockdown patchset

[Mimi Zohar]

On Tue, 2018-05-01 at 21:59 +0000, Matthew Garrett wrote:
> On Tue, May 1, 2018 at 2:50 PM Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> 
> > On Tue, 2018-05-01 at 21:02 +0000, Matthew Garrett wrote:
> > > Hm. My concern is that distributions are going to ship IMA in a
> > > configuration that allows users to add their own keys at boot time (it's
> > > difficult to use it in a generic way otherwise), and that's going to
> allow
> > > kexecing of arbitrary images without requiring physical access. I think
> > > kexec_file_load() needs to be relying on non-IMA signatures.
> 
> > I don't see how.  Unless the kernel was built with extra room for a
> > local CA public key (CONFIG_SYSTEM_EXTRA_CERTIFICATE), which would be
> > loaded onto the builtin keyring, there is no way of adding keys to the
> > IMA keyring.  Adding the extra public key would require the kernel to
> > be resigned.
> 
> Oh, is kexec verified off the _module keyring? We still end up with the
> problem that distributions don't have a mechanism to ship IMA signatures
> yet, but that avoids the user modification problem. I've just posted a
> patchset to debian-dpkg, we'll see how that goes.

I'm not aware of a _module keyring.  With IMA-appraisal, the signature
verification of the kernel image (kexec_file_load) uses the trusted
IMA keyring.  Nayna Jain posted a patch that defines a new platform
keyring[1], which would only be used to validate the kernel image and
initramfs signatures.

Your review would be much appreciated!

I really do hope that some version of including file signatures in
Debian packages will be upstreamed soon.  Good luck!

[1] https://lkml.org/lkml/2018/2/28/1089

Mimi

Re: linux-next: UEFI Secure boot lockdown patchset

[Matthew Garrett]

On Tue, May 1, 2018 at 3:21 PM Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:

> On Tue, 2018-05-01 at 21:59 +0000, Matthew Garrett wrote:
> > Oh, is kexec verified off the _module keyring? We still end up with the
> > problem that distributions don't have a mechanism to ship IMA signatures
> > yet, but that avoids the user modification problem. I've just posted a
> > patchset to debian-dpkg, we'll see how that goes.

> I'm not aware of a _module keyring.  With IMA-appraisal, the signature
> verification of the kernel image (kexec_file_load) uses the trusted
> IMA keyring.  Nayna Jain posted a patch that defines a new platform
> keyring[1], which would only be used to validate the kernel image and
> initramfs signatures.

INTEGRITY_KEYRING_MODULE is defined, but doesn't appear to be used
anywhere. Odd. Anyway, distributions are unlikely to ship with
CONFIG_INTEGRITY_TRUSTED_KEYRING since it makes it impossible for users to
determine which set of IMA or EVM signatures they want to trust. So if
validation is against the IMA keyring rather than builtin_trusted_keys,
it's going to be possible for users to extend the set of trusted keys. If
CONFIG_KEXEC_BZIMAGE_VERIFY_SIG is set then the kernel seems to do the
right thing here, but it's not clear to me how that's supposed to interact
with IMA?

Re: linux-next: UEFI Secure boot lockdown patchset

[Mimi Zohar]

On Tue, 2018-05-01 at 22:32 +0000, Matthew Garrett wrote:
> On Tue, May 1, 2018 at 3:21 PM Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> 
> > On Tue, 2018-05-01 at 21:59 +0000, Matthew Garrett wrote:
> > > Oh, is kexec verified off the _module keyring? We still end up with the
> > > problem that distributions don't have a mechanism to ship IMA signatures
> > > yet, but that avoids the user modification problem. I've just posted a
> > > patchset to debian-dpkg, we'll see how that goes.
> 
> > I'm not aware of a _module keyring.  With IMA-appraisal, the signature
> > verification of the kernel image (kexec_file_load) uses the trusted
> > IMA keyring.  Nayna Jain posted a patch that defines a new platform
> > keyring[1], which would only be used to validate the kernel image and
> > initramfs signatures.
> 
> INTEGRITY_KEYRING_MODULE is defined, but doesn't appear to be used
> anywhere. Odd. Anyway, distributions are unlikely to ship with
> CONFIG_INTEGRITY_TRUSTED_KEYRING since it makes it impossible for users to
> determine which set of IMA or EVM signatures they want to trust. So if
> validation is against the IMA keyring rather than builtin_trusted_keys,
> it's going to be possible for users to extend the set of trusted keys. If
> CONFIG_KEXEC_BZIMAGE_VERIFY_SIG is set then the kernel seems to do the
> right thing here, but it's not clear to me how that's supposed to interact
> with IMA?

>From your description, whatever keys the distros are loading onto the
builtin_trusted_keys keyring for verifying the kexec kernel image,
could just as easily be added to the IMA trusted keyring
(CONFIG_INTEGRITY_TRUSTED_KEYRING).  I don't see the difference.

Loading other keys requires reserving memory for a local CA public
key.

Mimi

Re: linux-next: UEFI Secure boot lockdown patchset

[Matthew Garrett]

On Tue, May 1, 2018 at 4:43 PM Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:

> On Tue, 2018-05-01 at 22:32 +0000, Matthew Garrett wrote:
> > INTEGRITY_KEYRING_MODULE is defined, but doesn't appear to be used
> > anywhere. Odd. Anyway, distributions are unlikely to ship with
> > CONFIG_INTEGRITY_TRUSTED_KEYRING since it makes it impossible for users
to
> > determine which set of IMA or EVM signatures they want to trust. So if
> > validation is against the IMA keyring rather than builtin_trusted_keys,
> > it's going to be possible for users to extend the set of trusted keys.
If
> > CONFIG_KEXEC_BZIMAGE_VERIFY_SIG is set then the kernel seems to do the
> > right thing here, but it's not clear to me how that's supposed to
interact
> > with IMA?

>  From your description, whatever keys the distros are loading onto the
> builtin_trusted_keys keyring for verifying the kexec kernel image,
> could just as easily be added to the IMA trusted keyring
> (CONFIG_INTEGRITY_TRUSTED_KEYRING).  I don't see the difference.

If CONFIG_INTEGRITY_TRUSTED_KEYRING isn't set then you can load new (and
unsigned) IMA keys from userspace. So if IMA is the lockdown control
mechanism for kexec, distros must either set
CONFIG_INTEGRITY_TRUSTED_KEYRING (which I don't think is practical) or IMA
should test kexec against the builtin_trusted_keys keyring rather than the
IMA keyring. Or have I misunderstood how this works?

Re: linux-next: UEFI Secure boot lockdown patchset

[Mimi Zohar]

On Tue, 2018-05-01 at 23:46 +0000, Matthew Garrett wrote:
> On Tue, May 1, 2018 at 4:43 PM Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> 
> > On Tue, 2018-05-01 at 22:32 +0000, Matthew Garrett wrote:
> > > INTEGRITY_KEYRING_MODULE is defined, but doesn't appear to be used
> > > anywhere. Odd. Anyway, distributions are unlikely to ship with
> > > CONFIG_INTEGRITY_TRUSTED_KEYRING since it makes it impossible for users
> to
> > > determine which set of IMA or EVM signatures they want to trust. So if
> > > validation is against the IMA keyring rather than builtin_trusted_keys,
> > > it's going to be possible for users to extend the set of trusted keys.
> If
> > > CONFIG_KEXEC_BZIMAGE_VERIFY_SIG is set then the kernel seems to do the
> > > right thing here, but it's not clear to me how that's supposed to
> interact
> > > with IMA?
> 
> >  From your description, whatever keys the distros are loading onto the
> > builtin_trusted_keys keyring for verifying the kexec kernel image,
> > could just as easily be added to the IMA trusted keyring
> > (CONFIG_INTEGRITY_TRUSTED_KEYRING).  I don't see the difference.
> 
> If CONFIG_INTEGRITY_TRUSTED_KEYRING isn't set then you can load new (and
> unsigned) IMA keys from userspace. So if IMA is the lockdown control
> mechanism for kexec, distros must either set
> CONFIG_INTEGRITY_TRUSTED_KEYRING (which I don't think is practical) or IMA
> should test kexec against the builtin_trusted_keys keyring rather than the
> IMA keyring. Or have I misunderstood how this works?

Another option is enabling both CONFIG_INTEGRITY_TRUSTED_KEYRING and
CONFIG_SYSTEM_EXTRA_CERTIFICATE.

Mimi