Security Working Group - Wednesday October 27

Security Working Group - Wednesday October 27

[Joseph Reynolds]

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?




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 October 27 - results

[Joseph Reynolds]

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

Re: Security Working Group - Wednesday October 27 - results

[Patrick Williams]

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

On Wed, Oct 27, 2021 at 02:11:15PM -0500, Joseph Reynolds wrote:
> On 10/26/21 8:12 AM, Joseph Reynolds wrote:
 
> 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.

Can we get some more details on this decision and a reply to the original ML
post?  It seemed like almost everyone was on-board with the initial proposal and
then a separate meeting with limited minutes was held which came to a different
conclusion.  This is out of sync.

I don't understand how "deterministic builds" is directly related to security
and I'd be immensely surprised if you could actually, today, build two images
from the exact same git commit and end up with a byte-wise identical build as
it is.

If someone seriously wants a reproducible build on their system they can easily
override this BUILD_ID value but it seems odd to me that:

    1. We would choose to purposefully deviate from what upstream Yocto does.
    2. We would punt on the usability issue that originally pushed us down
       pursuing any change here.

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

What is the escalation to be done?  Is there some stale-mate encountered or a
seeming disagreement on direction?  It seems to me like only 1 developer is
actively working on it and the progress has just been slow as a result.

-- 
Patrick Williams

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

Re: Security Working Group - Wednesday October 27 - results

[Patrick Williams]

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

On Wed, Oct 27, 2021 at 03:31:37PM -0500, Patrick Williams wrote:
> On Wed, Oct 27, 2021 at 02:11:15PM -0500, Joseph Reynolds wrote:
> > On 10/26/21 8:12 AM, Joseph Reynolds wrote:
>  
> > 1 FYA: Changing the os-release BUILD_ID back to its default value of 
...
> > DISCUSSION:
> > 
> > This was resolved: the project defaults are not being changed.
> 
> Can we get some more details on this decision and a reply to the original ML
> post?  It seemed like almost everyone was on-board with the initial proposal and
> then a separate meeting with limited minutes was held which came to a different
> conclusion.  This is out of sync.

I missed Adriana's follow up and thus I also misunderstood what you wrote here.
I think what you intended (please correct me) to communicate was:

    "It appears that the direction of this is now to not make the change, so
    there is nothing for us to discuss."

> I don't understand how "deterministic builds" is directly related to security
> and I'd be immensely surprised if you could actually, today, build two images
> from the exact same git commit and end up with a byte-wise identical build as
> it is.

I still stand by this part.  Can someone educate me on how deterministic builds
is related to security?  And, are deterministic builds already a stated security
goal for us?

> If someone seriously wants a reproducible build on their system they can easily
> override this BUILD_ID value but it seems odd to me that:
> 
>     1. We would choose to purposefully deviate from what upstream Yocto does.
>     2. We would punt on the usability issue that originally pushed us down
>        pursuing any change here.

I'll move this to the original thread.


-- 
Patrick Williams

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