Potential high risk for readonly/operator users on BMC console access
Thang Nguyen OS
thang at amperemail.onmicrosoft.com
Thu Dec 8 17:57:17 AEDT 2022
> On 6 Dec 2022, at 23:08, 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 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.
Thanks for your information. Actually I don’t know what the standard way is. Just a question, should we only allow priv-admin to access BMC console?
We can prevent non-admin users access the console by below change (the difference from your commit is just on the check condition):
diff --git a/user_mgr.cpp b/user_mgr.cpp
index 4a44b32..69cb329 100644
--- a/user_mgr.cpp
+++ b/user_mgr.cpp
@@ -307,7 +307,8 @@ void UserMgr::createUser(std::string userName,
throwForMaxGrpUserCount(groupNames);
std::string groups = getCSVFromVector(groupNames);
- bool sshRequested = removeStringFromCSV(groups, grpSsh);
+ removeStringFromCSV(groups, grpSsh);
+ bool sshRequested = (priv == "priv-admin");
// treat privilege as a group - This is to avoid using different file to
// store the same.
@@ -434,7 +435,8 @@ void UserMgr::updateGroupsAndPriv(const std::string& userName,
}
std::string groups = getCSVFromVector(groupNames);
- bool sshRequested = removeStringFromCSV(groups, grpSsh);
+ removeStringFromCSV(groups, grpSsh);
+ bool sshRequested = (priv == "priv-admin");
// treat privilege as a group - This is to avoid using different file to
// store the same.
>
> 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 -
>>
>
More information about the openbmc
mailing list