Security Working Group meeting - this Wednesday February 19 - summary results

Thu Feb 20 10:05:09 AEDT 2020

On 2/17/20 4:29 PM, Joseph Reynolds wrote:
> This is a reminder of the OpenBMC Security Working Group meeting 
> scheduled for this Wednesday February 19 at 10:00am PDT.

This meeting was held.  Only the first 7 items were discussed.  The 
remaining items stay on the list for next time (Wednesday March 4).

>
> We'll discuss current development items, and anything else that comes up.
>
> Ratan intends to participate and has requested that we cover the 
> following two items first:
> (A) service discovery direction, (B) using pam_abl
>
> The current topics:
>
> 1. (Joseph): Is OpenBMC affected by the Chrome browser’s SameSite 
> cookie changes 
> (https://blog.chromium.org/2020/02/samesite-cookie-changes-in-february.html)? 
> Do we want to enhance BMCWeb 
> (https://github.com/openbmc/bmcweb/blob/master/include/token_authorization_middleware.hpp#L430) 
> to create cookies with SameSite=None; Secure when 
> BMCWEB_INSECURE_DISABLE_XSS_PREVENTION is also used, to allow the BMC 
> to be used by the Chrome browser.  Perhaps by default BMCWeb should 
> generate cookies with SameSite=Strict?  

>
Joseph will create bmcweb issue for this.

> 2. (Joseph, follow up to agenda item 3 from 2020-02-05): Redfish 
> Privilege updates: 
> https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/28881 and 
> https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/28878 Update Feb 
> 11: See 
> https://redfishforum.com/thread/281/manageraccountcollection-change-allows-account-enumeration 
> clarified the intention to NOT enumerate all accounts (unless you are 
> the admin)

Consensus was to leave OpenBMC as-is (only admin can enumerate users) 
until Redfish releases a new spec.
>
> 3. (email) FYA.  BMC aggregator - includes a security topic. 
> https://lists.ozlabs.org/pipermail/openbmc/2020-February/020433.html 

Nancy plans to follow up.

>
> 4. (email) FYA - BMC Secure Boot / U-Boot - use dm-verity or 
> alternate? 
> https://lists.ozlabs.org/pipermail/openbmc/2020-February/020452.html 

Need BMC threat model to understand what threats dm-verity protects 
against.  Note that integrity protection is a defense in depth against 
an attacker who can run code on the BMC which writes to the BMC’s file 
system.

Is the BMC filesystem writeable?  ANS: It uses read-write overlay 
filesystem on /etc.  Idea: Could discontinue using overlays and use soft 
links to fs on read-write partition

>
> 5. Redfish forum question: Direction for channel based restrictions - 
> https://redfishforum.com/thread/279/channel-privilege-support-direction-redfish 

Redfish direction is to NOT change Role based on channel, and suggests 
implementations can offer a different set of accounts based on ingress 
channel (for example, based on which ethernet device (eth0, eth1, etc) 
the accessed the BMC).

OpenBMC community may have multiple use cases for a feature like this. 
Either the mgmt network or host may be more secure, and the other is 
less secure.

Idea: expose the list of channels within OpenBMC, and allow 
Account-Channel associations.  For example, an interface to allow 
“admin2” to access the BMC only from “eth0” or “eth1” but not “eth2”.

>
> 6. (Bruce via email):  BMCWeb Cert valid for 10 years - 
> https://lists.ozlabs.org/pipermail/openbmc/2020-February/020488.html 

Change BMCweb’s default self-signed cert to a maximum of 825 days.  
Recommend 30 days.

When this is done, if BMCWeb generates a self-signed cert, and it is not 
replaced, and the BMC’s time is sane, then browsers that connect to 
BMCWeb will start to complain after 30 days.

The recovery is: The BMC admin should install a valid BMCWeb site 
identity cert, then clients can re-connect to the BMC. (This will serve 
the updated cert and make the browser happy.)

The “BMC Admin guide” should talk about installing your own cert.

See docs here: https://github.com/openbmc/bmcweb/#configuration

Ass code here: 
https://github.com/openbmc/bmcweb/blob/91243c3b28b1df66e682f5a3ee96341fdc516b5a/include/ssl_key_handler.hpp#L205

Will there be a warning for the BMC admin (that the BMCWeb site cert 
will expire soon)?  (And don’t rely on a warning from the browser itself.)

>
> 7. (Joseph / James / Richard email): Rate limiting, use pam_abl - 
> https://lists.ozlabs.org/pipermail/openbmc/2020-February/020430.html 

There was concern about any account lockout mechanism locking out 
legitimate users; throttling is safer.

Next step is to design how this would be used.

>
> 8. (Joseph via email): New Redfish roles ServiceRep & OemRep - 
> https://lists.ozlabs.org/pipermail/openbmc/2020-February/020540.html 

>
> 9. (Joseph email): Implement the Redfish PasswordChangeRequired 
> property 
>  https://lists.ozlabs.org/pipermail/openbmc/2020-February/020554.html 

>
> 10. (Joseph email): delete BMCWeb sessions after some kinds of account 
> changes

> https://lists.ozlabs.org/pipermail/openbmc/2020-February/020555.html 

>

These item (8-10) were not address due to lack of time.  They remain for 
next time.

>
> Access, agenda, and notes are in the wiki:
>
> https://github.com/openbmc/openbmc/wiki/Security-working-group
>
> - Joseph
>
>