* Security Working Group - Wednesday May 26 @ 2021-05-26 13:43 Joseph Reynolds 2021-05-26 18:59 ` Security Working Group - Wednesday May 26 - results Joseph Reynolds 0 siblings, 1 reply; 6+ messages in thread From: Joseph Reynolds @ 2021-05-26 13:43 UTC (permalink / raw) To: openbmc 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Security Working Group - Wednesday May 26 - results 2021-05-26 13:43 Security Working Group - Wednesday May 26 Joseph Reynolds @ 2021-05-26 18:59 ` Joseph Reynolds 2021-05-27 12:56 ` Patrick Williams 0 siblings, 1 reply; 6+ messages in thread From: Joseph Reynolds @ 2021-05-26 18:59 UTC (permalink / raw) To: openbmc 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Security Working Group - Wednesday May 26 - results 2021-05-26 18:59 ` Security Working Group - Wednesday May 26 - results Joseph Reynolds @ 2021-05-27 12:56 ` Patrick Williams 2021-05-27 15:04 ` Joseph Reynolds 0 siblings, 1 reply; 6+ messages in thread From: Patrick Williams @ 2021-05-27 12:56 UTC (permalink / raw) To: Joseph Reynolds; +Cc: openbmc [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Security Working Group - Wednesday May 26 - results 2021-05-27 12:56 ` Patrick Williams @ 2021-05-27 15:04 ` Joseph Reynolds 2021-05-28 3:09 ` Andrew Jeffery 0 siblings, 1 reply; 6+ messages in thread From: Joseph Reynolds @ 2021-05-27 15:04 UTC (permalink / raw) To: Patrick Williams; +Cc: openbmc 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Security Working Group - Wednesday May 26 - results 2021-05-27 15:04 ` Joseph Reynolds @ 2021-05-28 3:09 ` Andrew Jeffery 2021-06-02 15:19 ` Ed Tanous 0 siblings, 1 reply; 6+ messages in thread From: Andrew Jeffery @ 2021-05-28 3:09 UTC (permalink / raw) To: Joseph Reynolds, Patrick Williams; +Cc: openbmc 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Security Working Group - Wednesday May 26 - results 2021-05-28 3:09 ` Andrew Jeffery @ 2021-06-02 15:19 ` Ed Tanous 0 siblings, 0 replies; 6+ messages in thread From: Ed Tanous @ 2021-06-02 15:19 UTC (permalink / raw) To: Andrew Jeffery; +Cc: openbmc, Joseph Reynolds 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-06-02 15:19 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-05-26 13:43 Security Working Group - Wednesday May 26 Joseph Reynolds 2021-05-26 18:59 ` Security Working Group - Wednesday May 26 - results Joseph Reynolds 2021-05-27 12:56 ` Patrick Williams 2021-05-27 15:04 ` Joseph Reynolds 2021-05-28 3:09 ` Andrew Jeffery 2021-06-02 15:19 ` Ed Tanous
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).