Potential high risk for readonly/operator users on BMC console access

Wed Dec 7 03:08:46 AEDT 2022

On 12/5/22 2:55 AM, Thang Nguyen OS wrote:
> On 2 Dec 2022, at 03: 42, Joseph Reynolds <jrey@ linux. ibm. com> 
> wrote: [EXTERNAL EMAIL NOTICE: This email originated from an external 
> sender. Please be mindful of safe email handling and proprietary 
> information protection practices. ] On
> ZjQcmQRYFpfptBannerStart
> This Message Is From an External Sender
> This message came from outside your organization.
> ZjQcmQRYFpfptBannerEnd
>> On 2 Dec 2022, at 03:42, Joseph Reynolds <jrey at linux.ibm.com> wrote:
>>
>> [EXTERNAL EMAIL NOTICE: This email originated from an external 
>> sender. Please be mindful of safe email handling and proprietary 
>> information protection practices.]
>>
>>
>> On 11/29/22 4:06 AM, Thang Nguyen OS wrote:
>>> Thanks for your feedback.
>>>
>>>> On 29 Nov 2022, at 08:41, Joseph Reynolds <jrey at linux.ibm.com> wrote:
>>>>
>>>> [EXTERNAL EMAIL NOTICE: This email originated from an external 
>>>> sender. Please be mindful of safe email handling and proprietary 
>>>> information protection practices.]
>>>>
>>>>
>>>> On 11/21/22 4:17 AM, Thang Nguyen OS wrote:
>>>>> Hi,
>>>>> I would like to have your comments on below issue which we think 
>>>>> it is high risk security issue which description below:
>>>>>
>>>>> Any user (read-only, operator, administrator), when created, has 
>>>>> BMC console access/login by default. He can login to BMC via BMC 
>>>>> console and do the following actions:
>>>>>  - Write to his /home/<user> folder to full. This will make the 
>>>>> RootFS full and no more operation can be done, unless do A/C power 
>>>>> and reflash the BMC from u-boot.
>>>>> - Write to /tmp folder to full which will make many application 
>>>>> fail to work.
>>>>> It is good for administrator as he should have full privilege. 
>>>>> However, for readonly/operator users, he should not have console 
>>>>> access. No matter if he makes the BMC crashed by mistake or it is 
>>>>> his intention, we should prevent his happens.
>>>>> It is known that many production systems do not support BMC 
>>>>> console but still have some support and some companies allow 
>>>>> remote access via KVM or console server. I think we should disable 
>>>>> shell login for normal users (readonly and operator) by default.
>>>> Thanks for your report.  Here are my thoughts.
>>>>
>>>> You are describing resource exhaustion, sometimes denoted as one of:
>>>> - CWE-400: Uncontrolled Resource Consumption
>>>> - CWE-770: Allocation of Resources Without Limits or Throttling
>>>>
>>>> I agree this will lead to the failure of various BMC functions leading
>>>> to denial of service.
>>>>
>>>> There are two ways to access the BMC command shell:
>>>>
>>>> 1. Access to the BMC command shell via SSH port 22.  The default BMC
>>>> configuration only allows Administrator users to have access. 
>>>> [footnote 1]
>>> No problem with SSH. Operator and read-only users can’t access BMC 
>>> shell over SSH
>>>> 2. Access to the BMC command shell via the BMC's serial port.  The
>>>> typical BMC setup either does not have a console or specifies that
>>>> access to the BMC's physical console port should be protected.
>>>>
>>>> Please see some related build-time configuration options here:
>>>> https://github.com/openbmc/openbmc/wiki/Configuration-guide#bmc-console-shell-access
>>>>
>>>> Also, we can consider adding a check so that only admin users are
>>>> allowed to access to a BMC command shell via the BMC's serial console.
>>>> (And non-admin user will be logged off.)
>>> Do you think we should disable console access by setting from 
>>> phosphor-user-manager during user creation? The alternative command 
>>> from BMC shell is usermode <user> -s /sbin/nologin
>>
>> I believe all non-admin users have their default shell set to
>> /bin/nologin per code in phosphor user manager:
>> https://github.com/openbmc/phosphor-user-manager/blob/master/user_mgr.cpp
>> Search for "nologin”.
> Unfortunately not. I tried to create new read-only users from WebUi 
> using latest codes from github.com/openbmc/openbmc 
> <http://github.com/openbmc/openbmc> but the users can still login to 
> BMC console.
> from 
> https://github.com/openbmc/phosphor-user-manager/blob/7562658e1fce6e19b55063955a5803e19f8f10b6/user_mgr.cpp#L1354, 
> it is based on sshRequested to set shell to /bin/sh or /sbin/nologin 
> but I wonder how can we configure it.

Thang,

I don't know the right way to configure this behavior.

There is a stub section in an OpenBMC doc which introduces the BMC UART 
serial interface we have been discussing, here:
https://github.com/openbmc/docs/blob/master/architecture/interface-overview.md#bmc-serial
and I would be happy to help with enhancements to describe user access.

IBM's public downstream fork has a custom configuration for SSH and BMC 
console access which does something like you are asking about:
https://github.com/ibm-openbmc/phosphor-user-manager/commit/16ec770914d2be3c407aced14fbca46ac9824f83
I would be happy to change this implementation to a standard way.

Joseph

>>
>> When reading this code, not only priv-admin users will have the "ssh"
>> group role per
>> https://github.com/openbmc/docs/blob/master/architecture/user-management.md#supported-group-roles
>>
>> Joseph
>>
>>
>>> - Joseph
>>>
>>>
>>> Footnote 1:
>>> The effect of the following is to configure the dropbear SSH server so
>>> only users who are in the priv-admin Linux group are allowed to connect
>>> via SSH.
>>> This config parameter:
>>> https://github.com/openbmc/openbmc/blob/master/meta-phosphor/recipes-core/dropbear/dropbear/dropbear.default
>>> Is configured into the image from here:
>>> https://github.com/openbmc/openbmc/blob/master/meta-phosphor/recipes-core/dropbear/dropbear_%25.bbappend
>>> and is used on the dropbear command line from here:
>>> https://github.com/openbmc/openbmc/blob/master/poky/meta/recipes-core/dropbear/dropbear/dropbear%40.service
>>>
>>>
>>>
>>>
>>>>> Thanks,
>>>>> Thang Q. Nguyen -
>