Closed joseph-reynolds closed 2 years ago
refresh
We should show how network users ingress into the BMC so BMC admins understand how to disable access.
The following diagram is a simplified view of how a network agent accesses a BMC interface, authenticates, and accesses a function.
Network agent
|
+--|-----------------------------
| | BMC
| V
| Network interface:
| one of
| - HTTPS
| - SSH
| - IPMI
| - etc.
| |
| V
| Authentication of user: local accounts and optionally LDAP
| root, adminuser, joeuser, etc.
| |
| V
| Function:
| - Redfish REST APIs
| - Secure Shell
| - IPMI server
| - etc.
+--------------------------------
The BMC admin can control access in these ways:
refresh
refresh
refresh
refresh
refresh
refresh
I came up with a draft version of the wording to help users understand what “enabled and disabled” mean for each item. My best guesses are in the bullets below, but we will probably have to tweak the wording (because I am not an expert in each of those areas):
refresh
Should we add SoL to the list? It is a similar access as KVMIP which is on the list. See https://lists.ozlabs.org/pipermail/openbmc/2020-April/021148.html
I've proposed adding ManagerNetworkProtocol.Oem.OpenBMC.mDNS as the mechanism for the BMC admin to enable and disable the BMC's Avahi mDNS service.
refresh
refresh
refresh
refresh
refresh
refresh
Progress on REST APIs to disable out of band IPMI (aka network IPMI) ~ https://lists.ozlabs.org/pipermail/openbmc/2020-May/021686.html
refresh
refresh
refresh
refresh
refresh
refresh
refresh
refresh
refresh
refresh
refresh
refresh
refresh
refresh
refresh
refresh
Desire to disable the Redfish protocol stated here: https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/35457/8//COMMIT_MSG#51
refresh
This table summarizes the work needed to disable interfaces through the BMC's architectural layers. The interfaces are listed across the top. The layers are listed down the left side. Each cell details the solution or work needed.
WORK IN PROGRESS -- please edit for correctness
Work items | Network IPMI | SSH | HTTPS | phys USB | RTAD (host) |
---|---|---|---|---|---|
WebUI | #1273 | #1273 | #1273 | #1273 | #1273 |
Redfish API | #513 | #1763 | #1763 | #1781 | BIOS settings (Ratan) |
D-Bus | done? (need refefence) | same | same | #1793 | |
lower-level | n/a | n/a | n/a | #1793 |
No support is planned to disable:
See also:
refresh
refresh
refresh
refresh
refresh
refresh
refresh
refresh
refresh
refresh
@joseph-reynolds is looking into how the current design being proposed will impact a system if there were to be quick enable and disable of settings. This is based partially on this comment:
Having the ability to disable shell access in regular scenarios would be good, as long as we can re-enable without too much disruption to the state of the BMC. https://github.com/ibm-openbmc/dev/issues/612#issuecomment-492121453
The current design would allow the user to enable and disable without any confirmation, so the changes to the same setting could be made rapidly. We want to assure, given the comment about potential disruption to system state, the proposed interface without any confirmation to the user to make the change is acceptable.
On the question of: What is the effect of disabling an interface, or enabling that interface, and should a GUI interface tell an admin what the effects are (like with help text) or require confirmation (like with a modal dialog box to confirm)?
These are currently DRAFT text, are not recommendations for help text (these may be too obvious to explain), and have NOT been reviewed by either technical development (for accuracy) or information development (technical writers, for clarity).
ipmitool
command.In general, for all interfaces: Having an interface enabled exposes you to newly discovered security vulnerabilities in that interface. However, the decision to disable an interface must be balance with requirements to operate and service the system. For example, you could disable the BMC's "SSH port 22" and re-enable it only as needed for service.
Expected Delivery Dates
Stakeholders
SME: Joseph Reynolds Design Researcher: @ParishrutB @priyanka-pillai97 UX Designer: @ParishrutB @priyanka-pillai97 FED: @dixsie
Use Case
The BMC admin should have an option to disable BMC shell access as a way to ensure the system is managed only by its intended interfaces (like Redfish REST APIs). Security conscious users will want to disable shell access when build the OpenBMC image or when provision their BMC. They require that, for example, to better control and log use of the BMC's management functions, and to pass audits. Use cases are (1) large-scale data centers where uniform access is desired, and (2) systems with sensitive (personal, financial, etc.) data where shell access constitutes a back door into the system.
Specifically, when disabled, secure shell (ssh) access to the BMC (
ssh -p 22
) will fail. Note that ssh access to the host console (viassh -p 2200
) is not affected by this design.The admin will be able to re-enable access, allow the BMC shell to be used for some function, debugging, or whatever, and then disable access again. Presumably use of the shell will be a rare event and closely watched to ensure no back doors into the BMC are created.
The BMC admin should be able to log the fact that BMC shell access was disabled or re-enabled. For example, if the design implements the Redfish ManagerNetworkProtocol SSH property (reference below), then Redfish REST API logging would suffice. The BMC admin should also be able to log ssh connection attempts, for example, log files written by the ssh server, PAM, etc.
Requirements
Design
We don't want the GUI to turn this function on or off by accident. My crude GUI design sketch: I envision a new status field on the admin page that shows if "BMC shell access is enabled" (and clearly indicate this feature is separate from the "host console ssh" feature). Maybe have a way to change its state, indicating one of:
Development
Shell access will remain enabled by default in the current OpenBMC releases.
InVision Prototype
Design Issue (phosphor-webui)
Development Issue
References/Resources