Bug#996202: systemd - EFI Secure Boot for systemd-boot

2021-11-18 Thread Julian Andres Klode
On Thu, Nov 18, 2021 at 05:02:59PM +0100, Michael Biebl wrote:
> Am 18.11.21 um 16:58 schrieb Julian Andres Klode:
> > On Thu, Nov 18, 2021 at 04:26:47PM +0100, Michael Biebl wrote:
> > > 
> > > Am 18.11.21 um 15:21 schrieb Julian Andres Klode:
> > > > we have recently discussed the matter of systemd-boot in
> > > > an upstream shim review gathering.
> > > 
> > > Is this discussion public? Can you share it?
> > 
> > We unfortunately do not have a written record of it.
> 
> private cabal, eh :-)
> 
> > > > * systemd-boot does not use current ways of communicating with
> > > > shim
> > > > 
> > > > * There was some concern over general quality
> > > 
> > > Has this been passed along to the systemd maintainers?
> > > If so, what's their take on this? If not, could you forward your
> > > findings/concerns to upstream, please?
> > 
> > It's not really my place, that's a discussion for other people
> > to have, and I don't have all the details.
> 
> Well, who if not you? I mean you said you are (part of) shim upstream?
> If you reject it, it would be good to actually have a bit more details then
> just meh, not going to happen.
> 
> That doesn't feel right.
> 

I understand how you feel, but I don't have anything to add at
the moment. I did not raise those two concerns, and I don't know
enough details to follow through on them.

I'm not sure if the people who have looked into it want to bother
actually proactively filing reports rather than wait for the situation
where a distro wants to have a grub-free, systemd-boot shim.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en


signature.asc
Description: PGP signature


Bug#996202: systemd - EFI Secure Boot for systemd-boot

2021-11-18 Thread Michael Biebl

Am 18.11.21 um 16:58 schrieb Julian Andres Klode:

On Thu, Nov 18, 2021 at 04:26:47PM +0100, Michael Biebl wrote:


Am 18.11.21 um 15:21 schrieb Julian Andres Klode:

we have recently discussed the matter of systemd-boot in
an upstream shim review gathering.


Is this discussion public? Can you share it?


We unfortunately do not have a written record of it.


private cabal, eh :-)


* systemd-boot does not use current ways of communicating with
shim

* There was some concern over general quality


Has this been passed along to the systemd maintainers?
If so, what's their take on this? If not, could you forward your
findings/concerns to upstream, please?


It's not really my place, that's a discussion for other people
to have, and I don't have all the details.


Well, who if not you? I mean you said you are (part of) shim upstream?
If you reject it, it would be good to actually have a bit more details 
then just meh, not going to happen.


That doesn't feel right.



OpenPGP_signature
Description: OpenPGP digital signature


Bug#996202: systemd - EFI Secure Boot for systemd-boot

2021-11-18 Thread Julian Andres Klode
On Thu, Nov 18, 2021 at 04:26:47PM +0100, Michael Biebl wrote:
> 
> Am 18.11.21 um 15:21 schrieb Julian Andres Klode:
> > we have recently discussed the matter of systemd-boot in
> > an upstream shim review gathering.
> 
> Is this discussion public? Can you share it?

We unfortunately do not have a written record of it.
> 
> 
> > * systemd-boot does not use current ways of communicating with
> >shim
> > 
> > * There was some concern over general quality
> 
> Has this been passed along to the systemd maintainers?
> If so, what's their take on this? If not, could you forward your
> findings/concerns to upstream, please?

It's not really my place, that's a discussion for other people
to have, and I don't have all the details.

> > * systemd-boot is an additional bootloader, rather than replacing
> >an existing one, thus increasing the attack surface.
> > 
> >If people want to experiment with other bootloaders than the
> >default one, they can disable secure boot, or load their own
> >keys into the machine. We do not consider it valid to have
> >a choice of bootloaders.
> 
> I guess with this argument, there can never be another bootloader aside from
> grub2?

We don't have a precedent for a distro that does not use grub (but a
different boot loader), so can't say for sure what would happen. But
as long as grub is signed by the keys trusted by the shim, there cannot
be non-grub bootloaders trusted by it as well, yes.

Presumably given that all shims are signed by MS in the end it does not
make sense to every sign any shim trusting a non-grub2 bootloader.

One thing I forgot to mention is that of course people can also
self-sign systemd-boot and put their certificate into the MOK instead
of replacing the entire db keys.

> Actually my impression by being vastly more minimalistic then grub2,
> systemd-shim would have a smaller attack surface.

On the one hand yes, but as the shim trusts both, the attack surface
overall widens. You can attack a machine by inserting either a grub or
a shim binary.


> Anyway, I don't really have any skin in this game, but I guess with the
> response from Julian this MR is dead in the water. It would be pretty
> pointless to prepare everything for systemd-shim to be signed when in the
> end it will never happen.

Yeah, sorry.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en


signature.asc
Description: PGP signature


Bug#996202: systemd - EFI Secure Boot for systemd-boot

2021-11-18 Thread Michael Biebl


Am 18.11.21 um 15:21 schrieb Julian Andres Klode:

we have recently discussed the matter of systemd-boot in
an upstream shim review gathering.


Is this discussion public? Can you share it?



* systemd-boot does not use current ways of communicating with
   shim

* There was some concern over general quality


Has this been passed along to the systemd maintainers?
If so, what's their take on this? If not, could you forward your 
findings/concerns to upstream, please?




* systemd-boot is an additional bootloader, rather than replacing
   an existing one, thus increasing the attack surface.

   If people want to experiment with other bootloaders than the
   default one, they can disable secure boot, or load their own
   keys into the machine. We do not consider it valid to have
   a choice of bootloaders.


I guess with this argument, there can never be another bootloader aside 
from grub2?
Actually my impression by being vastly more minimalistic then grub2, 
systemd-shim would have a smaller attack surface.


Anyway, I don't really have any skin in this game, but I guess with the 
response from Julian this MR is dead in the water. It would be pretty 
pointless to prepare everything for systemd-shim to be signed when in 
the end it will never happen.


Regards,
Michael




OpenPGP_signature
Description: OpenPGP digital signature


Bug#996202: systemd - EFI Secure Boot for systemd-boot

2021-11-18 Thread Julian Andres Klode
Hi Bastian,

we have recently discussed the matter of systemd-boot in
an upstream shim review gathering.

We reject a signing of systemd-boot as

* systemd-boot does not use current ways of communicating with
  shim

* There was some concern over general quality

* systemd-boot is an additional bootloader, rather than replacing
  an existing one, thus increasing the attack surface.

  If people want to experiment with other bootloaders than the
  default one, they can disable secure boot, or load their own
  keys into the machine. We do not consider it valid to have
  a choice of bootloaders.

I want to note that the current shim has been signed with the
understanding that it will trust grub, kernels, and fwupd. A
signing of systemd-boot might be considered reasons for revoking
the existing shim, and will certainly result in new shims not
getting signed.

On Thu, Nov 18, 2021 at 02:17:22PM +0100, Bastian Blank wrote:
> Hi Julian
> 
> Given that I got no reply from you after four weeks, I consider that
> issue not existing.
> 
> Bastian
> 
> On Wed, Oct 20, 2021 at 11:12:23AM +0200, Bastian Blank wrote:
> > On Tue, Oct 12, 2021 at 03:31:24PM +0200, Bastian Blank wrote:
> > > On Tue, Oct 12, 2021 at 02:52:57PM +0200, Julian Andres Klode wrote:
> > > > On Tue, Oct 12, 2021 at 02:41:01PM +0200, Bastian Blank wrote:
> > > > > Yes.  This is just for signing right now.
> > > > I wouldn't do that. You then end up breaking users when introducing
> > > > integration; or need yet another package to host the integration in.
> > > 
> > > Hu?  It does not break it any more then the current state.  The systemd
> > > package already ships an EFI binary without any integration.
> > > 
> > > > shim 15.4 requires SBAT sections on binaries it loads.
> > > > So systemd-boot does not hook into shim at all IIRC, so it's not
> > > > super useful - you can't load Debian kernels with it, only stuff
> > > > in UEFI db (other shims, basically).
> > > 
> > > > If it gets signed to be loadable by shim, it would have to implement
> > > > verification of loaded binaries using the shim, and provide an SBAT
> > > > section so shim even bothers loading it.
> > > 
> > > systemd-boot can add proper SBAT as far as I see.  Maybe not in the
> > > version currently on Debian unstable.  Also I see some calls into
> > > SHIM_LOCK.  So there is both SBAT support and support for the shim
> > > verification protocol.
> 
> -- 
> There's another way to survive.  Mutual trust -- and help.
>   -- Kirk, "Day of the Dove", stardate unknown

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en



Bug#996202: systemd - EFI Secure Boot for systemd-boot

2021-11-18 Thread Bastian Blank
On Tue, Oct 12, 2021 at 01:14:53PM +0200, Bastian Blank wrote:
> > I don't have any experience with Secure Boot (especially in Debian's
> > context), so would need help with that.
> > Would you mind prepping a MR?
> Sure, can do.

See
https://salsa.debian.org/systemd-team/systemd/-/merge_requests/132

I talked to the masters of the secure boot key.  We will sign it with a
test key until some security review has been done, so it can't be used
in the Debian secure boot context for now.

Regards,
Bastian

-- 
Women professionals do tend to over-compensate.
-- Dr. Elizabeth Dehaver, "Where No Man Has Gone Before",
   stardate 1312.9.



Bug#996202: systemd - EFI Secure Boot for systemd-boot

2021-11-18 Thread Bastian Blank
Hi Julian

Given that I got no reply from you after four weeks, I consider that
issue not existing.

Bastian

On Wed, Oct 20, 2021 at 11:12:23AM +0200, Bastian Blank wrote:
> On Tue, Oct 12, 2021 at 03:31:24PM +0200, Bastian Blank wrote:
> > On Tue, Oct 12, 2021 at 02:52:57PM +0200, Julian Andres Klode wrote:
> > > On Tue, Oct 12, 2021 at 02:41:01PM +0200, Bastian Blank wrote:
> > > > Yes.  This is just for signing right now.
> > > I wouldn't do that. You then end up breaking users when introducing
> > > integration; or need yet another package to host the integration in.
> > 
> > Hu?  It does not break it any more then the current state.  The systemd
> > package already ships an EFI binary without any integration.
> > 
> > > shim 15.4 requires SBAT sections on binaries it loads.
> > > So systemd-boot does not hook into shim at all IIRC, so it's not
> > > super useful - you can't load Debian kernels with it, only stuff
> > > in UEFI db (other shims, basically).
> > 
> > > If it gets signed to be loadable by shim, it would have to implement
> > > verification of loaded binaries using the shim, and provide an SBAT
> > > section so shim even bothers loading it.
> > 
> > systemd-boot can add proper SBAT as far as I see.  Maybe not in the
> > version currently on Debian unstable.  Also I see some calls into
> > SHIM_LOCK.  So there is both SBAT support and support for the shim
> > verification protocol.

-- 
There's another way to survive.  Mutual trust -- and help.
-- Kirk, "Day of the Dove", stardate unknown



Bug#996202: systemd - EFI Secure Boot for systemd-boot

2021-10-20 Thread Bastian Blank
Hi Julian

Ping?

On Tue, Oct 12, 2021 at 03:31:24PM +0200, Bastian Blank wrote:
> On Tue, Oct 12, 2021 at 02:52:57PM +0200, Julian Andres Klode wrote:
> > On Tue, Oct 12, 2021 at 02:41:01PM +0200, Bastian Blank wrote:
> > > Yes.  This is just for signing right now.
> > I wouldn't do that. You then end up breaking users when introducing
> > integration; or need yet another package to host the integration in.
> 
> Hu?  It does not break it any more then the current state.  The systemd
> package already ships an EFI binary without any integration.
> 
> > shim 15.4 requires SBAT sections on binaries it loads.
> > So systemd-boot does not hook into shim at all IIRC, so it's not
> > super useful - you can't load Debian kernels with it, only stuff
> > in UEFI db (other shims, basically).
> 
> > If it gets signed to be loadable by shim, it would have to implement
> > verification of loaded binaries using the shim, and provide an SBAT
> > section so shim even bothers loading it.
> 
> systemd-boot can add proper SBAT as far as I see.  Maybe not in the
> version currently on Debian unstable.  Also I see some calls into
> SHIM_LOCK.  So there is both SBAT support and support for the shim
> verification protocol.

-- 
Vulcans believe peace should not depend on force.
-- Amanda, "Journey to Babel", stardate 3842.3



Bug#996202: systemd - EFI Secure Boot for systemd-boot

2021-10-12 Thread Bastian Blank
On Tue, Oct 12, 2021 at 02:52:57PM +0200, Julian Andres Klode wrote:
> On Tue, Oct 12, 2021 at 02:41:01PM +0200, Bastian Blank wrote:
> > Yes.  This is just for signing right now.
> I wouldn't do that. You then end up breaking users when introducing
> integration; or need yet another package to host the integration in.

Hu?  It does not break it any more then the current state.  The systemd
package already ships an EFI binary without any integration.

> shim 15.4 requires SBAT sections on binaries it loads.
> So systemd-boot does not hook into shim at all IIRC, so it's not
> super useful - you can't load Debian kernels with it, only stuff
> in UEFI db (other shims, basically).

> If it gets signed to be loadable by shim, it would have to implement
> verification of loaded binaries using the shim, and provide an SBAT
> section so shim even bothers loading it.

systemd-boot can add proper SBAT as far as I see.  Maybe not in the
version currently on Debian unstable.  Also I see some calls into
SHIM_LOCK.  So there is both SBAT support and support for the shim
verification protocol.

Bastian

-- 
You!  What PLANET is this!
-- McCoy, "The City on the Edge of Forever", stardate 3134.0



Bug#996202: systemd - EFI Secure Boot for systemd-boot

2021-10-12 Thread Julian Andres Klode
On Tue, Oct 12, 2021 at 02:41:01PM +0200, Bastian Blank wrote:
> On Tue, Oct 12, 2021 at 02:22:11PM +0200, Julian Andres Klode wrote:
> > The proposed implementation adds signing, but not any hooks for
> > installing kernels? Anyway I don't care much I guess, sicherboot
> > would take an unsigned binary, but it also handles a signed one
> > I guess.
> 
> Yes.  This is just for signing right now.

I wouldn't do that. You then end up breaking users when introducing
integration; or need yet another package to host the integration in.

> 
> > I think the more important question is whether people will make use
> > of it, and it's worthwhile dealing with the security impact. Presumably
> > systemd-boot also needs to gain support for SBAT, and both have an SBAT
> > section and perform verification of SBAT levels, which I'm not sure
> > anybody has worked on yet, see
> 
> What is the current state of SBAT support? 
> 
> Also, AFAIK the complete image verification is done in shim.  Why would
> downstream loaders require SBAT verification on their own?

shim 15.4 requires SBAT sections on binaries it loads.

So systemd-boot does not hook into shim at all IIRC, so it's not
super useful - you can't load Debian kernels with it, only stuff
in UEFI db (other shims, basically).

If it gets signed to be loadable by shim, it would have to implement
verification of loaded binaries using the shim, and provide an SBAT
section so shim even bothers loading it.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en



Bug#996202: systemd - EFI Secure Boot for systemd-boot

2021-10-12 Thread Bastian Blank
On Tue, Oct 12, 2021 at 02:22:11PM +0200, Julian Andres Klode wrote:
> The proposed implementation adds signing, but not any hooks for
> installing kernels? Anyway I don't care much I guess, sicherboot
> would take an unsigned binary, but it also handles a signed one
> I guess.

Yes.  This is just for signing right now.

> I think the more important question is whether people will make use
> of it, and it's worthwhile dealing with the security impact. Presumably
> systemd-boot also needs to gain support for SBAT, and both have an SBAT
> section and perform verification of SBAT levels, which I'm not sure
> anybody has worked on yet, see

What is the current state of SBAT support? 

Also, AFAIK the complete image verification is done in shim.  Why would
downstream loaders require SBAT verification on their own?

Bastian

-- 
Well, Jim, I'm not much of an actor either.



Bug#996202: systemd - EFI Secure Boot for systemd-boot

2021-10-12 Thread Michael Biebl

Am 12.10.21 um 11:22 schrieb Bastian Blank:

Package: systemd
Version: 247.9-4
Severity: wishlist

Hi folks

systemd already includes it's own small and EFI based bootloader.  To
make it more widely usable, it would be nice to have it secure boot
signed.  Signing for secure boot is supported in Debian via a round trip
inside the archive.

I would implement that something in the line of:

- Split off the existing EFI binary into a new package
   "systemd-boot-unsigned".
- Create the template package "systemd-boot-$arch-signed-template".  It
   contains a list of files to be signed and a source package template,
   which gets signatures injected into and uploaded by the signing
   process.
- The template creates a source and binary package
   "systemd-boot-$arch-signed", shipping the signed EFI binary.
- Add a "systemd-boot" package that contains "bootctl" and a dependency
   on "systemd-boot-$arch-signed".

I can help with that, as I'm going work on secure boot anyway.


Looping in Julian. As maintainer of sicherboot, I assume he would be 
affected by this change.

Julian, maybe you have some input as well.

Regards,
Michael



OpenPGP_signature
Description: OpenPGP digital signature


Bug#996202: systemd - EFI Secure Boot for systemd-boot

2021-10-12 Thread Bastian Blank
On Tue, Oct 12, 2021 at 01:10:37PM +0200, Michael Biebl wrote:
> > I would implement that something in the line of:
> > 
> > - Split off the existing EFI binary into a new package
> >"systemd-boot-unsigned".
> > - Create the template package "systemd-boot-$arch-signed-template".  It
> >contains a list of files to be signed and a source package template,
> >which gets signatures injected into and uploaded by the signing
> >process.
> > - The template creates a source and binary package
> >"systemd-boot-$arch-signed", shipping the signed EFI binary.
> > - Add a "systemd-boot" package that contains "bootctl" and a dependency
> >on "systemd-boot-$arch-signed".
> 
> Would all those binary packages be built from src:systemd?

>From the perspective of the maintainer: yes.  Everything comes out of
src:systemd.

In perspective of the archive: no.  Secure boot in Debian is done in two
steps.

src:systemd will provide:
- systemd-boot
- systemd-boot-unsigned
- systemd-boot-$arch-signed-template

src:systemd-boot-$arch-signed is created internally and will provide:
- systemd-boot-$arch-signed

> I don't have any experience with Secure Boot (especially in Debian's
> context), so would need help with that.
> Would you mind prepping a MR?

Sure, can do.

Regards,
Bastian

-- 
Those who hate and fight must stop themselves -- otherwise it is not stopped.
-- Spock, "Day of the Dove", stardate unknown



Bug#996202: systemd - EFI Secure Boot for systemd-boot

2021-10-12 Thread Michael Biebl

Hi Bastian

Am 12.10.21 um 11:22 schrieb Bastian Blank:

Package: systemd
Version: 247.9-4
Severity: wishlist

Hi folks

systemd already includes it's own small and EFI based bootloader.  To
make it more widely usable, it would be nice to have it secure boot
signed.  Signing for secure boot is supported in Debian via a round trip
inside the archive.

I would implement that something in the line of:

- Split off the existing EFI binary into a new package
   "systemd-boot-unsigned".
- Create the template package "systemd-boot-$arch-signed-template".  It
   contains a list of files to be signed and a source package template,
   which gets signatures injected into and uploaded by the signing
   process.
- The template creates a source and binary package
   "systemd-boot-$arch-signed", shipping the signed EFI binary.
- Add a "systemd-boot" package that contains "bootctl" and a dependency
   on "systemd-boot-$arch-signed".


Would all those binary packages be built from src:systemd?
I don't have any experience with Secure Boot (especially in Debian's 
context), so would need help with that.

Would you mind prepping a MR?

Regards,
Michael



OpenPGP_signature
Description: OpenPGP digital signature


Bug#996202: systemd - EFI Secure Boot for systemd-boot

2021-10-12 Thread Bastian Blank
Package: systemd
Version: 247.9-4
Severity: wishlist

Hi folks

systemd already includes it's own small and EFI based bootloader.  To
make it more widely usable, it would be nice to have it secure boot
signed.  Signing for secure boot is supported in Debian via a round trip
inside the archive.

I would implement that something in the line of:

- Split off the existing EFI binary into a new package
  "systemd-boot-unsigned".
- Create the template package "systemd-boot-$arch-signed-template".  It
  contains a list of files to be signed and a source package template,
  which gets signatures injected into and uploaded by the signing
  process.
- The template creates a source and binary package
  "systemd-boot-$arch-signed", shipping the signed EFI binary.
- Add a "systemd-boot" package that contains "bootctl" and a dependency
  on "systemd-boot-$arch-signed".

I can help with that, as I'm going work on secure boot anyway.

Regards,
Bastian

-- 
There is an order of things in this universe.
-- Apollo, "Who Mourns for Adonais?" stardate 3468.1