Security Working Group - Wednesday October 27 - results

Thu Oct 28 06:11:15 AEDT 2021

On 10/26/21 8:12 AM, Joseph Reynolds wrote:
> This is a reminder of the OpenBMC Security Working Group meeting 
> scheduled for this Wednesday October 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.Changing the os-release BUILD_ID back to its default value of 
> DATETIME (recipe os-release.bb) - 
> https://lore.kernel.org/openbmc/CAH2-KxB6P2HTE5iqJMx1Gwrrq_w2-gXCZ47ZXaO_x5kZ2RAzCg@mail.gmail.com/T/#m0065dab191fe8048ea02ab3c28b31362252f7622 
> <https://lore.kernel.org/openbmc/CAH2-KxB6P2HTE5iqJMx1Gwrrq_w2-gXCZ47ZXaO_x5kZ2RAzCg@mail.gmail.com/T/#m0065dab191fe8048ea02ab3c28b31362252f7622>(background 
> reference: https://man7.org/linux/man-pages/man5/os-release.5.html 
> <https://man7.org/linux/man-pages/man5/os-release.5.html>).
>
> Will the builder need to supply BUILD_ID to maintain a stable (aka 
> deterministic, aka reproducible) build?
>

Attended: Joseph R, Bruce Mitchell, Vernon M, Jiang Zhang, Dhananjay 
Phadke, James Mihm

The meeting ran about 25 minutes overtime (1h 25m total).

1 FYA: Changing the os-release BUILD_ID back to its default value of 
DATETIME (recipe os-release.bb) - 
https://lore.kernel.org/openbmc/CAH2-KxB6P2HTE5iqJMx1Gwrrq_w2-gXCZ47ZXaO_x5kZ2RAzCg@mail.gmail.com/T/#m0065dab191fe8048ea02ab3c28b31362252f7622 
<https://lore.kernel.org/openbmc/CAH2-KxB6P2HTE5iqJMx1Gwrrq_w2-gXCZ47ZXaO_x5kZ2RAzCg@mail.gmail.com/T/#m0065dab191fe8048ea02ab3c28b31362252f7622>(background 
reference: https://man7.org/linux/man-pages/man5/os-release.5.html 
<https://man7.org/linux/man-pages/man5/os-release.5.html>).

 1.

    Will the builder need to supply BUILD_ID to maintain a stable (aka
    deterministic, aka reproducible) build?

 2.

    https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/48204
    <https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/48204>

 3.

    https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/48205
    <https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/48205>

DISCUSSION:

This was resolved: the project defaults are not being changed.

2 (Joseph, followup): discuss progress toward (1) using github 
advisories, and (2) the Security Response Team’s (SRT) using a private 
github issues database.

DISCUSSION:

This was discussed at two separate times during the meeting.  The first 
discussion notes:

Must test, e.g., no leaks to discord.

The second discussion notes:

To clarify: the private database is needed by the OpenBMC security 
response team (SRT) to organize the security problems which were 
reported and are not yet made public.  For background, see: 
https://github.com/openbmc/docs/blob/master/security/how-to-report-a-security-vulnerability.md 
<https://github.com/openbmc/docs/blob/master/security/how-to-report-a-security-vulnerability.md>

Access to the database would be given to the Openbmc SRT members, plus 
access to each issue is given to the problem reporter and the people 
working on that problem.

Please reply to the email thread “start using github security 
advisories” Oct 13-18.  Example: 
https://lore.kernel.org/openbmc/cd2f6175-475f-0e5a-0b65-4f7a12959ab6@linux.vnet.ibm.com/ 
<https://lore.kernel.org/openbmc/cd2f6175-475f-0e5a-0b65-4f7a12959ab6@linux.vnet.ibm.com/>

We resolved to create the issues database and test it with real but 
well-known vulnerabilities.

We also discussed how the project handles Linux kernel security issues, 
like how we fix CVEs:

  *

    Joel Stanley is active in this area - https://github.com/openbmc/linux/

  *

    Our security wiki
    (https://github.com/openbmc/openbmc/wiki/Security-working-group)
    describes how: Yocto security
    <https://wiki.yoctoproject.org/wiki/Security>efforts flow directly
    into the OpenBMC project.  For example, Yocto puts security fixes
    into its fix branches.

3 Continued discussion: IPMI password over DTLS

DISCUSSION:

Per Vernon, Opaque is not mature and Intel prefers SCRAM or sending 
cleartext username+password through the secure channel (similar to basic 
auth https://en.wikipedia.org/wiki/Basic_access_authentication 
<https://en.wikipedia.org/wiki/Basic_access_authentication>).

Could use scram.  Preferred because it can detect man in the middle 
attack via channel binding.

Looking for scram implementation.

Will add to https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/31548 
<https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/31548>

Staging question: Do we need a protocol to support certificate auth, vs 
password auth via basicAuth or scram?

Would DTLS remove RMCP+’s 20 character password limit.  Yes.

4 Questions about: Password strength (cleartext), lockout after failed 
password attempts

DISCUSSION:

See AccountLockoutDuration and AccountLockoutThreshold in the 
https://github.com/openbmc/openbmc/wiki/Configuration-guide 
<https://github.com/openbmc/openbmc/wiki/Configuration-guide>

See  MinPasswordLength property in 
https://github.com/openbmc/bmcweb/blob/master/redfish-core/lib/account_service.hpp 
<https://github.com/openbmc/bmcweb/blob/master/redfish-core/lib/account_service.hpp>

Which is brought into the BMC image via recipe: 
https://github.com/openbmc/openbmc/blob/master/poky/meta/recipes-extended/pam/libpam/pam.d/common-auth 
<https://github.com/openbmc/openbmc/blob/master/poky/meta/recipes-extended/pam/libpam/pam.d/common-auth>and 
is customized by OpenBMC here: 
https://github.com/openbmc/openbmc/blob/master/meta-phosphor/recipes-extended/pam/libpam/pam.d/common-auth 
<https://github.com/openbmc/openbmc/blob/master/meta-phosphor/recipes-extended/pam/libpam/pam.d/common-auth>with 
pam_tally2 docs here: 
https://man7.org/linux/man-pages/man8/pam_tally2.8.html 
<https://man7.org/linux/man-pages/man8/pam_tally2.8.html>  for example, 
“even_deny_root”.

Do these policies apply to root users?  It doesn’t look like it, per 
https://github.com/openbmc/openbmc/blob/2b59705148feb8ca6aafd9cf050229b069284515/meta-phosphor/recipes-extended/pam/libpam/pam.d/common-auth#L11 
<https://github.com/openbmc/openbmc/blob/2b59705148feb8ca6aafd9cf050229b069284515/meta-phosphor/recipes-extended/pam/libpam/pam.d/common-auth#L11>

Ideally remove root user logins.

We discussed using Linux “capabilities” so we don’t need root (uid=0) 
processes.

Is this general topic (“https://github.com/openbmc/openbmc/issues/3383 
<https://github.com/openbmc/openbmc/issues/3383>”) important enough to 
escalate to the Technical oversight  forum (TOF)?

>
>
>
> 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