Re: overlayFS security concern - threat model

[Kun Zhao <zkxz@hotmail.com>]

Thanks, Joseph. Seems we have several options to solve the problem.

Kun

On 2/22/2021 9:36 AM, Joseph Reynolds wrote:
> On 2/19/21 6:31 PM, Kun Zhao wrote:
>> Hi Team, Have the following case ever been discussed before?,...
>> This Message Is From an External Sender
>> This message came from outside your organization.
>>
>> Hi Team,
>>
>> Have the following case ever been discussed before?,
>>
>> Anyone knows the root password will be able to let bmc run their own 
>> code by scp the code into bmc with the same file path as any services 
>> in rootfs. It will make the secure boot totally useless.
>>
>> So besides,
>>
>> 1. disable scp (but scp is one of the firmware upload way)
>>
>> 2. don’t use overlayFS (but it’s really useful for debugging during 
>> develop, and configuration management)
>>
>> Any other solutions?
>>
>
> Kun,
>
> Thanks for starting this thread.  Good discussion everyone!  Note 
> OpenBMC's SSH interfaces are described in 
> [network-security-considerations][].
>
> I would like to improve the project's threat model to cover these 
> ideas and so propose a new document, threat-model-considerations.md, 
> to go under [OpenBMC security docs][] with topics:
>
> - OpenBMC has a well-known password.
>     - Explanation: OpenBMC has a well-known root password.  There is 
> no mechanism which forces anyone to change it.
>     - Risk: OpenBMC's default configuration produce firmware which has 
> a well-known password which allows an attacker to gain full access to 
> BMC internals.
>     - Recommendation: Three independent recommendations:
>         1. Provide a [configuration guide][] for firmware builders 
> which instructs them to change the default password for their distro, 
> and similar for BMC administrators which instructs them to change the 
> default password when they first access the BMC.
>         2. Implement an image option to cause the BMC's initial 
> password to be expired so it must be changed before access is granted.
>         3. Move away from password-based authentication.
>     - Caveat: The expired password solution leaves a time window when 
> the BMC is available to attackers and has well known password.
>
> - Root account login to the BMC's command shell.
>     - Explanation: Root access to the BMC's command shell is required 
> for developers and service personnel to do their job. (They need to 
> access the BMC internal tools and interfaces.)  But root access is not 
> needed for any administrators or users performing normal BMC functions.
>     - Risk: Users will have more authority than they need to do their 
> job.  (The BMC should be designed so the owner can give each user the 
> authority they nee, but no more.)  Additional authority may allow a 
> user or attacker to damage BMC internals or gain information about the 
> host they are not intended to have.
>     - Recommendation: Disable root access in production images. 
> (Should we have an OpenBMC image feature to control this?)  If root 
> access is no disabled, it must be strictly limited to authorized users.
>
> - SSH access to the BMC (including scp firmware update).
>     - Explanation: The BMC provides an SSH server to allow secure 
> shell (ssh) sessions to the BMC's command shell, ssh sessions to the 
> host console, and scp-based firmware update.
>     - Risk: See the "Root account login to the BMC's command shell" 
> topic.  Note that ssh access to the host console is intended.
>     - Recommendation: As above, disable SSH access for production 
> images.  Disable SCP and instead use Redfish firmware update.
>
> - Running unintended code on the BMC.
>     - Explanation: The BMC is intended as a closed appliance but runs 
> Linux.
>     - Risk: The BMC's Linux capabilities allow an attacker who gains 
> access to the BMC to attack the BMC's network and attack the BMC's host.
>     - Recommendation: Use technologies like SecureBoot and Integrity 
> Measurement Architecture (IMA).
>     - Caveats: Powerful scripting tools such as the command shell (sh 
> or bash) would be allowed by IMA to run on the BMC but still give an 
> attacker the ability to run harmful code.
>
> - Having writable portions of the BMC's file system
>     - Explanation: The BMC is intended as a closed appliance with a 
> read-only file system but has a writable portions of the file system 
> to store BMC admin-configurable items, firmware updates, internal and 
> host logs, etc.
>     - Risk: The BMC's writable file system allows an attacker who 
> gains access to the BMC to make their access permanent by writing to 
> the BMC's file system.
>     - Recommendation: Strictly limit which portions of the BMC's file 
> system are writable.  For example, to /var, /run, and a strict subset 
> of /etc.  Use a non-persistent overlay for data that does not need to 
> persist beyond a BMC reboot.
>
> I've added this topic to the [OpenBMC security working group 
> agenda][].  But please keep the discussion going in the email list.
>
> Thanks!
> -Joseph
>
> [network-security-considerations]: 
> https://github.com/openbmc/docs/blob/master/security/network-security-considerations.md
> [OpenBMC security docs]: 
> https://github.com/openbmc/docs/blob/master/security
> [configuration guide]: 
> https://github.com/openbmc/openbmc/wiki/Configuration-guide
> [OpenBMC security working group agenda]: 
> https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI 
>
>
>>
>> Thanks.
>>
>> Kun
>>
>