* Security Working Group meeting - Wednesday July 20
@ 2022-07-20 3:47 Joseph Reynolds
2022-07-20 23:05 ` Security Working Group meeting - Wednesday July 20 - results Joseph Reynolds
0 siblings, 1 reply; 2+ messages in thread
From: Joseph Reynolds @ 2022-07-20 3:47 UTC (permalink / raw)
To: openbmc
This is a reminder of the OpenBMC Security Working Group meeting
scheduled for this Wednesday July 20 at 10:00am PDT.
We'll discuss the following items on the agenda
<https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI>,
and anything else that comes up:
1. Continue discussing CVE response, SELinux, and Measured Boot 2.
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] 2+ messages in thread
* Re: Security Working Group meeting - Wednesday July 20 - results
2022-07-20 3:47 Security Working Group meeting - Wednesday July 20 Joseph Reynolds
@ 2022-07-20 23:05 ` Joseph Reynolds
0 siblings, 0 replies; 2+ messages in thread
From: Joseph Reynolds @ 2022-07-20 23:05 UTC (permalink / raw)
To: openbmc
On 7/19/22 10:47 PM, Joseph Reynolds wrote:
> This is a reminder of the OpenBMC Security Working Group meeting
> scheduled for this Wednesday July 20 at 10:00am PDT.
>
> We'll discuss the following items on the agenda
> <https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI>,
> and anything else that comes up:
>
> 1. Continue discussing CVE response, SELinux, and Measured Boot 2.
Meeting held 2022-07-20
Attendees: Daniil Engranov, Russel Wilson, Yutaka Sugawara, Ruud Haring,
James Mihm, Joseph Reynolds, Dhananjay, Jiang Zhang, Krishnan Sugavanam,
Sandhya Koteshwara
1 CVE Response guidelines
The OpenBMC Security Response Team is meeting regularly to determine
next steps for how to improve the vulnerability handling process. See
background docs here:
https://github.com/openbmc/docs/blob/master/security/obmc-security-response-team.md
<https://github.com/openbmc/docs/blob/master/security/obmc-security-response-team.md>
The direction is to move new problems into github advisories as quickly
as possible.
For example, security vulnerabilities in OpenBMC documentation are
reported in https://github.com/openbmc/docs/security/advisories
<https://github.com/openbmc/docs/security/advisories>, BMCWeb defects
reported in https://github.com/openbmc/bmcweb/security/advisories
<https://github.com/bmcweb/docs/security/advisories>, etc. Each repo
has its own set of security advisories.
The team is working to understand how to give security responders access
to private security advisories. Obviously, then we would have to work
with each repository maintainer to set up its security tab.
2 SELinux updates.
We discussed ideas for the right way to structure the code. The
consensus is there are three layers:
Layer 1. Use the existing meta-selinuxbitbake layer. This layer has the
poky/meta config changes to use selinux: adds the SELinux support,
updates coreutils, and introduces policies.
Layer 2: Propose a new bitbake layer, meta-phosphor-selinux, to work on
top of the meta-selinux layer, to adapt the OpenBMC phosphor
applications to use SElinux. This approach avoids changing the base
repos, so they don’t need to know or care about SELinux. This further
customizes openbmc:
1.
Override various recipes via *.bbappend to add selinux to recipes
like busybox, pam, more updates to coreutils, etc.
2.
Define minimal/trivial SELinux policies for OpenBMC applications
Layer 3: Add detailed SELinux policy files to the existing meta- layers
for each target. For example, add SELinux policies to the OpenPOWER
platform (the OpenBMC reference platform)
https://github.com/openbmc/meta-ibm/blob/master/conf/machine/witherspoon.conf
This would do thing like:
1.
Increase size of the readonly file system (which is per TARGET).
2.
Introduce policy files for that target (test FEATURE to know if
selinux is enabled).
This three layer approach puts the parts that can be shared into the new
meta-phosphor-selinux layer, and leaves policy decisions to each TARGET
machine.
To add SELinux to a machine or a build, the configuration work would be
here:
1.
Insert the meta-selinux layer
2.
Insert the meta-phosphor-selinux layer
3.
Enhance the layer for your target.
3 TPM/attestation updates.
Working on PoC for the following:
*
Working to extend measurements to the TPM
*
Working to integrate keylime for remote attestation.
Next steps are to create a design for the step above. For remote
attestation: An agent on the BMC collects data. How can a network
client get that data? WIP: Redfish schema for network clients to get
access to read attestation. Is there a common solution? We want to
avoid OEM APIs.
Redfish public discussion here:
https://redfishforum.com/thread/685/support-bmc-attached-tpm
<https://redfishforum.com/thread/685/support-bmc-attached-tpm>
>
> 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] 2+ messages in thread
end of thread, other threads:[~2022-07-20 23:06 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-20 3:47 Security Working Group meeting - Wednesday July 20 Joseph Reynolds
2022-07-20 23:05 ` Security Working Group meeting - Wednesday July 20 - results Joseph Reynolds
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.