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

Joseph Reynolds jrey at
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 
> ( 
> Do we want to enhance BMCWeb 
> ( 
> to create cookies with SameSite=None; Secure when 
> 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: 
> and 
> Update Feb 
> 11: See 
> 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. 

Nancy plans to follow up.

> 4. (email) FYA - BMC Secure Boot / U-Boot - use dm-verity or 
> alternate? 

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 

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 - 

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 - 

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:

Ass code here:

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 - 

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 - 

> 9. (Joseph email): Implement the Redfish PasswordChangeRequired 
> property 

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


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

More information about the openbmc mailing list