Security Working Group meeting - Wednesday April 27

Security Working Group meeting - Wednesday April 27

[Joseph Reynolds]

This is a reminder of the OpenBMC Security Working Group meeting 
scheduled for this Wednesday April 27 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.




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 meeting - Wednesday April 27 - results

[Joseph Reynolds]

On 4/27/22 7:31 AM, Joseph Reynolds wrote:
> This is a reminder of the OpenBMC Security Working Group meeting 
> scheduled for this Wednesday April 27 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:
>

Attendees: Joseph Reynolds, Ruud Haring, Dhananjay, Jiang Ziang, Daniil, 
Nirav Shah, Mark McCawley, Terry Duncan.


1 Followup to SELinux discussion from last time.

TODO Joseph: post the session recording and the presentation.

Note design in gerrit review 
https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/53205 
<https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/53205>

We clarified the goal of the design is to make it easy for a system 
integrator to add SELinux to their BMC firmware image, and to set some 
basic SELinux policies which do not create “too many” denial event log 
entries when SELinux is switched to permissive mode.  The usefulness of 
this design is to collect data for policies needed to switch SELinux to 
enforcing mode.  It remains an open question what policies are generally 
useful to the OpenBMC community.


Dhananjay mentioned a SELinux policy analysis tool:

https://ossna2020.sched.com/event/ckpF/selint-an-selinux-policy-static-analysis-tool-daniel-burgener-microsoft 
<https://ossna2020.sched.com/event/ckpF/selint-an-selinux-policy-static-analysis-tool-daniel-burgener-microsoft>

https://www.youtube.com/watch?v=Gx5bxwvzN_Y 
<https://www.youtube.com/watch?v=Gx5bxwvzN_Y>


2 Is there a tie-in between Penetration testing and SELinux?

Note: Pen testing is performed by individual platforms, and the testing 
effort is not shared: only  vulnerabilities and fixes are shared.  Help 
wanted at the community level.

The idea is that the same kind of analysis is needed for both Pen 
testing and to make SELinux policy.  Can we share that analysis or 
develop it in the OpenBMC community?


3 Nirav Shah - Alternate idea: Use D-Bus session buses (vs the system bus).

Note that all OpenBMC applications use the D-Bus system bus, which only 
the root user is allowed to access.

Nirav presented an idea to change some applications to use a session bus 
(and away from the system bus).  Doing so allows BMC applications to run 
as non-root and makes it easier for different applications to 
communicate via D-bus APIs.

We believe this work is relatively independent of SELinux policy 
configuration.



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 meeting - Wednesday April 27 - results

[Patrick Williams]

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

On Wed, Apr 27, 2022 at 01:07:49PM -0500, Joseph Reynolds wrote:
> On 4/27/22 7:31 AM, Joseph Reynolds wrote:

> 3 Nirav Shah - Alternate idea: Use D-Bus session buses (vs the system bus).
> 
> Note that all OpenBMC applications use the D-Bus system bus, which only 
> the root user is allowed to access.
> 
> Nirav presented an idea to change some applications to use a session bus 
> (and away from the system bus).  Doing so allows BMC applications to run 
> as non-root and makes it easier for different applications to 
> communicate via D-bus APIs.
> 
> We believe this work is relatively independent of SELinux policy 
> configuration.

In my opinion, architectural changes like this fall pretty far outside
of "Security" and need pretty wide consensus.  It's fine if you want to
use the Security Workgroup to refine the idea but I want to be clear
that acceptance by the Security Workgroup isn't sufficient to move
forward.

-- 
Patrick Williams

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