Security Working Group - Wednesday May 26

Security Working Group - Wednesday May 26

[Joseph Reynolds]

This is a reminder of the OpenBMC Security Working Group meeting 
scheduled for this Wednesday May 26 at 10:00am PDT.

We'll discuss the following items on the agenda 
<https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI/edit>, 
and anything else that comes up:

1. Followup from last meeting re uboot, kexec, sysrq-trigger on ARM 
architecture.
2. Interest in reviewing TLS protocols supported?


Access, agenda and notes are in the wiki:
https://github.com/openbmc/openbmc/wiki/Security-working-group 
<https://github.com/openbmc/openbmc/wiki/Security-working-group>

- Joseph

Re: Security Working Group - Wednesday May 26 - results

[Joseph Reynolds]

On 5/26/21 8:43 AM, Joseph Reynolds wrote:
> This is a reminder of the OpenBMC Security Working Group meeting 
> scheduled for this Wednesday May 26 at 10:00am PDT.
>
> We'll discuss the following items on the agenda 
> <https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI/edit>, 
> and anything else that comes up:
>
Bonus topic 0: We overviewed OpenBMC's security assurance documentation 
at the start of the meeting.

> 1. Followup from last meeting re uboot, kexec, sysrq-trigger on ARM 
> architecture.
We re-hashed the discussion, added new information, and added new concerns.


> 2. Interest in reviewing TLS protocols supported?
Yes.  We discussed CBC ciphers and HMACs.  Should we disable client 
renegotiation?
Then we re-hashed the discussion about the HTTPS self-signed certificate 
10 year duration.

Items added after the agenda was emailed:
3. user-manager: authentication & password management helper for 
netipmid and bmcweb for non-root environment to drop direct PAM use. 
Privilege separation and Master processes to handle users’ sessions
DISCUSSION:
Idea: Forward all authentication & password change & account change 
requests to user-manager which would then need to be enhanced to check 
authority when a request is made.  Then phosphor-user-manager would need 
root-like authority or a Linux capability to use PAM to change any 
user’s password.
Does phosphor-user-manager also need to be (or work in tandem with) a 
session manager?  Then we can remove session management from IPMI 
network and from BMCWeb, which would be modified to use user-manager.

Also consider how session-less unauthenticated host-IPMI would work.

- Joseph

>
>
> Access, agenda and notes are in the wiki:
> https://github.com/openbmc/openbmc/wiki/Security-working-group 
> <https://github.com/openbmc/openbmc/wiki/Security-working-group>
>
> - Joseph

Re: Security Working Group - Wednesday May 26 - results

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 2692 bytes --]

On Wed, May 26, 2021 at 01:59:57PM -0500, Joseph Reynolds wrote:
> On 5/26/21 8:43 AM, Joseph Reynolds wrote:
 
> > 1. Followup from last meeting re uboot, kexec, sysrq-trigger on ARM 
> > architecture.
> We re-hashed the discussion, added new information, and added new concerns.

Could you paste the minutes here when you reply to these?  It is kind of
hard to have any discussion with the rest of the community when you have
2-3 levels of indirection to get at the words.

> We think there are cultural differences between Linux and open source
> with respect to how we handle security items (but we didn't get into any
> details).

It is really hard to know what this is referring to or means or how it
might impact us.  There is no such thing as "open source" as something
different and separate from "Linux".  Certainly many sub-communities
within the OSS world have different priorities and approaches when it
comes to security.  This sounds like it was just idle chatter.

> Kernel's modules expect BMC hardware to be in a particular state. Kernel
> kexec’ing might lead to undefined behavior for such modules.

I think we're just talking about normal bugs here.  Those would be
caught and fixed in testing, wouldn't they?

> Worried about interactions with secure boot.
> Scenario: kernel 1 boots, then the BMC gets compromised, then kernel 2
> is kexec’d.

What is the "worry" here?  This isn't an unsolved problem as servers
have to deal with this all the time.

This is why secureboot itself isn't really all that useful without
attestation.  There are going to be compromised images.  You put them in
a block list.  When you kexec, since you haven't gone through a reset,
the TPM still contains the measurements from the compromised / blocked
image (which have now been extende with the kexec measurements as well).
So any system running code that is in your block list is still blocked
because you can't trust that it wasn't compromised.

> Kexec does not significantly improve the boot time of BMC.

And?  Was someone suggesting it would?  Not sure the context.

It seems like whoever is involved in these discussions is missing the
purpose of enabling kexec.  I don't think anyone is talking about using
kexec as a way to make some minor improvement in a once-in-a-while
OpenBMC upgrade + reboot path.

Kexec is being talked about because it is *the way you get kernel debug*
now.  Kdump requires kexec.  When the kernel crashes, you kexec to the
kdump kernel, it garthers a bunch of data, hopefully stores it in flash,
and then you can do a proper reboot back to your buggy-crashing kernel.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Security Working Group - Wednesday May 26 - results

[Joseph Reynolds]

On 5/27/21 7:56 AM, Patrick Williams wrote:
> On Wed, May 26, 2021 at 01:59:57PM -0500, Joseph Reynolds wrote:
>> On 5/26/21 8:43 AM, Joseph Reynolds wrote:
>   
>>> 1. Followup from last meeting re uboot, kexec, sysrq-trigger on ARM
>>> architecture.
>> We re-hashed the discussion, added new information, and added new concerns.
> Could you paste the minutes here when you reply to these?  It is kind of
> hard to have any discussion with the rest of the community when you have
> 2-3 levels of indirection to get at the words.

Thanks for your email!

Yes, I've waffled between cut/paste of the minutes and summarizing 
them.  I prefer to cut/paste, so I'll do that consistently from now on.

>> We think there are cultural differences between Linux and open source
>> with respect to how we handle security items (but we didn't get into any
>> details).
> It is really hard to know what this is referring to or means or how it
> might impact us.  There is no such thing as "open source" as something
> different and separate from "Linux".  Certainly many sub-communities
> within the OSS world have different priorities and approaches when it
> comes to security.  This sounds like it was just idle chatter.


I wasn't sure what this meant when it was said.  It believe it refers to 
my floundering interactions with 
https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/42948
Nobody at the meeting followed up on that statement. I've since address 
the comment in the review.

>> Kernel's modules expect BMC hardware to be in a particular state. Kernel
>> kexec’ing might lead to undefined behavior for such modules.
> I think we're just talking about normal bugs here.  Those would be
> caught and fixed in testing, wouldn't they?
>
>> Worried about interactions with secure boot.
>> Scenario: kernel 1 boots, then the BMC gets compromised, then kernel 2
>> is kexec’d.
> What is the "worry" here?  This isn't an unsolved problem as servers
> have to deal with this all the time.
>
> This is why secureboot itself isn't really all that useful without
> attestation.  There are going to be compromised images.  You put them in
> a block list.  When you kexec, since you haven't gone through a reset,
> the TPM still contains the measurements from the compromised / blocked
> image (which have now been extende with the kexec measurements as well).
> So any system running code that is in your block list is still blocked
> because you can't trust that it wasn't compromised.

The worry is that security boot is not a complete solution, as you 
pointed out.

>> Kexec does not significantly improve the boot time of BMC.
> And?  Was someone suggesting it would?  Not sure the context.
>
> It seems like whoever is involved in these discussions is missing the
> purpose of enabling kexec.  I don't think anyone is talking about using
> kexec as a way to make some minor improvement in a once-in-a-while
> OpenBMC upgrade + reboot path.
>
> Kexec is being talked about because it is *the way you get kernel debug*
> now.  Kdump requires kexec.  When the kernel crashes, you kexec to the
> kdump kernel, it garthers a bunch of data, hopefully stores it in flash,
> and then you can do a proper reboot back to your buggy-crashing kernel.

I get the same feeling.  Using kexec was brought up in the context of 
kernel debug, and the conversation wandered off. :-(

- Joseph

Re: Security Working Group - Wednesday May 26 - results

[Andrew Jeffery]

On Fri, 28 May 2021, at 00:34, Joseph Reynolds wrote:
> On 5/27/21 7:56 AM, Patrick Williams wrote:
> > On Wed, May 26, 2021 at 01:59:57PM -0500, Joseph Reynolds wrote:
> >> On 5/26/21 8:43 AM, Joseph Reynolds wrote:
> >   
> >>> 1. Followup from last meeting re uboot, kexec, sysrq-trigger on ARM
> >>> architecture.
> >> We re-hashed the discussion, added new information, and added new concerns.
> > Could you paste the minutes here when you reply to these?  It is kind of
> > hard to have any discussion with the rest of the community when you have
> > 2-3 levels of indirection to get at the words.
> 
> Thanks for your email!
> 
> Yes, I've waffled between cut/paste of the minutes and summarizing 
> them.  I prefer to cut/paste, so I'll do that consistently from now on.

+1, it makes it much easier for people who can't attend to provide input.

The other thing I'd like to see is attendance / attribution of 
comments, that way I know who I need discuss particular items with.

Cheers,

Andrew

Re: Security Working Group - Wednesday May 26 - results

[Ed Tanous]

On Thu, May 27, 2021 at 8:10 PM Andrew Jeffery <andrew@aj.id.au> wrote:
>
>
>
> On Fri, 28 May 2021, at 00:34, Joseph Reynolds wrote:
> > On 5/27/21 7:56 AM, Patrick Williams wrote:
> > > On Wed, May 26, 2021 at 01:59:57PM -0500, Joseph Reynolds wrote:
> > >> On 5/26/21 8:43 AM, Joseph Reynolds wrote:
> > >
> > >>> 1. Followup from last meeting re uboot, kexec, sysrq-trigger on ARM
> > >>> architecture.
> > >> We re-hashed the discussion, added new information, and added new concerns.
> > > Could you paste the minutes here when you reply to these?  It is kind of
> > > hard to have any discussion with the rest of the community when you have
> > > 2-3 levels of indirection to get at the words.
> >
> > Thanks for your email!
> >
> > Yes, I've waffled between cut/paste of the minutes and summarizing
> > them.  I prefer to cut/paste, so I'll do that consistently from now on.
>
> +1, it makes it much easier for people who can't attend to provide input.
>
> The other thing I'd like to see is attendance / attribution of
> comments, that way I know who I need discuss particular items with.

+1

>
> Cheers,
>
> Andrew