overlayFS security concern - threat model

[Joseph Reynolds]

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
>